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About This Guide 


+ 


+ 


Open Enterprise Server (OES) 2015 SP1 is the next generation of the Novell services that have long 
been valued by a wide variety of businesses and other organizations, ranging from small businesses 


Chapter 1, “Frequently Asked Questions,” on page 9 

Chapter 2, “Getting Started,” on page 23 

Chapter 3, “Upgrading eDirectory to OES,” on page 31 

Chapter 4, “Upgrading NSS and Data Storage to OES,” on page 45 
Chapter 5, “Upgrading File Services to OES,” on page 51 

Chapter 6, “Upgrading Print Services to OES,” on page 71 

Chapter 7, “Upgrading Backup Services to OES,” on page 75 
Chapter 8, “Upgrading Network Services to OES,” on page 77 
Chapter 9, “Upgrading Novell Cluster Services to OES,” on page 83 
Chapter 10, “Upgrading Other Novell Products to OES,” on page 87 
Chapter 11, “About Third-Party Applications,” on page 93 

Appendix A, “Tools for Upgrading to OES,” on page 95 

Appendix B, “About the Management Tools in OES,” on page 99 
Appendix C, “Workstation Considerations,” on page 103 

Appendix D, “Server Consolidation,” on page 105 

Appendix E, “Examples,” on page 107 


to multi-national enterprises. 


When you install OES 2015 SP1, you install SUSE Linux Enterprise Server (SLES) 11 SP4 as the 


core OS and the OES components as an “add-on product.” 


What This Guide Provides 


This guide provides an overview of the planning and implementation processes involved in upgrading 
from NetWare to OES 2015 SP1. It provides overview and planning information along with links to 


specific implementation instructions. 


What This Guide Does Not Replace 


This guide does not replace the specific upgrading and planning instructions found in the regular 
installation and migration guides that you should follow carefully to ensure a successful upgrade to 


OES. 


Audience 


This guide is intended for network administrators. 


About This Guide 
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Feedback 


We want to hear your comments and suggestions about this manual and the other documentation 
included with OES 2015 SP1. Please use the User Comments feature at the bottom of each page of 
the online documentation. 


Documentation Updates 


For the most recent version of this guide, see the OES 2015 SP1 Documentation Web site (http:// 
www.novell.com/documentation/oes2015). 


Documentation Conventions 


In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and 
items in a cross-reference path. 
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1.1 


Frequently Asked Questions 


You probably have a few questions up front. Here are some answers. 


Section 1.1, “Why Not Stay on NetWare?,” on page 9 

Section 1.2, “What About My Older NetWare Servers?,” on page 10 

Section 1.3, “What’s New in OES?,” on page 10 

Section 1.4, “What Do Novell Customers Recommend?,” on page 10 

Section 1.5, “What Are the Differences Between NetWare and OES?,” on page 12 

Section 1.6, “How Much Training Is Needed?,” on page 20 

Section 1.7, “What Training Is Available?,” on page 21 

Section 1.8, “Does Novell Have Community Support to Help Me with My Migration?,” on page 22 


Why Not Stay on NetWare? 


There are distinct advantages to moving to OES over staying on NetWare. 


For more information about latest features on OES, see What’s New or Changed in OES 2015 SP1 in 
the OES 2015 SP1: Readme. 


Here are a few of the benefits of upgrading to OES: 


+ 


NetWare Entered Extended Support in 2010: As Novell cautioned for a number of years, 
NetWare entered its extended support phase in 2010. 


Continued Hardware Support: When NetWare entered extended support, hardware vendors 
ceased to certify it on new server hardware. 


Continued Third-party Solutions Support: As hardware vendors ceased certification support, 
third-party software solutions providers, such as anti-virus and backup software vendors, 
stopped developing for the NetWare platform. 


Dynamic Storage Technology: This breakthrough Novell technology drastically reduces 
storage costs and runs only on OES, not on NetWare. However, NSS volumes on NetWare can 
be assigned as secondary volumes in a pair. 


iFolder 3.9: NetWare supports only Novell iFolder 2.x, which lacks important features found in 
the latest version, such as automatic server provisioning, multiple iFolders per user, iFolder 
sharing between users, reassigning iFolder ownership, provisioning for LDAP groups, and 
numerous administrative enhancements. 


Open Source Solutions: Open source initiatives such as Apache and Tomcat have been 
supported on NetWare only as Novell or others have ported them to the platform, but they are 
automatically available on OES. 


Virtualization technologies: Xen and KVM are no-cost virtualization solutions that run on OES 
servers. The Xen solution lets you create NetWare virtual machines for those services that you 
want to keep on NetWare for the time being. Both solutions support OES virtual machines. 


Domain Services for Windows: This OES technology integrates eDirectory and Active 
Directory users as well as Windows and Novell file services. 


Frequently Asked Questions 
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10 


1.2 


1.3 


1.4 


¢ File Systems: OES not only supports the Novell Storage Services (NSS) file system, but also 
traditional Linux file systems, such as Ext3, XFS, and Btrfs. 


+ Novell Services enhancements: As Novell services continue to evolve, the new features and 
technologies are available on OES. 


What About My Older NetWare Servers? 


NetWare 6.5 SP8 is the primary source server targeted by the OES Migration Tool. 


Earlier versions of NetWare should be upgraded to OES 2015 SP1 as outlined in Table 1-1. 


Table 1-1 Upgrade Paths from Earlier Versions of NetWare 


NetWare Version Minimum DS Tool to Use Other Information 
Version 

NetWare 4.11 SP9 NDS 6.21 n/a You must perform a down-server 
upgrade to NetWare 5.1 SP8 as an 
interim step. 

NetWare 4.2 NDS 6.21 n/a You must perform a down-server 
upgrade to NetWare 5.1 SP8 as an 
interim step. 

NetWare 5.0 SP6a NDS 7.62c of 8.85c n/a You must perform a down-server 


upgrade to NetWare 5.1 SP8 as an 
interim step. 


NetWare 5.1 SP8 


eDirectory 8.7.3.7 or 
later 


OES Migration Tool 


For more information, see “Transfer ID 
Migration” in the OES 2015 SP1: 
Migration Tool Administration Guide. 


NetWare 6.0 SP5 


eDirectory 8.7.3.7 or 
later 


OES Migration Tool 


For more information, see “Transfer ID 
Migration” in the OES 2015 SP1: 
Migration Tool Administration Guide. 


What’s New in OES? 


The “What’s New or Changed in OES 2015 SP1” section in the OES 2015 SP1: Readme includes 
information on the new features that are only available in OES. 


What Do Novell Customers Recommend? 


The table below summarizes customer advice from a survey of OES customers. 


Table 1-2 What Novell Customers Say about OES 


Customer Tip 


Learn basic Linux skills first (before starting) or have someone handy who knows about it. Make 
sure you: 
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Customer Tip 
+ Understand the Linux file system and rights. 


For help, see “Understanding Directory Structures in Linux POSIX File Systems” in the OES 2015 
SP1: File Systems Management Guide and “Aligning NCP and POSIX File Access Rights” in the 
OES 2015 SP1: Planning and Implementation Guide 


+ Know Linux command line tools for the equivalent NetWare commands (DSTrace, DSRepair, etc.). 
Learn the commands by setting up a test server and playing out the scenario you want to see on 
your production server. 


For help, see the OES 2015 SP1: Linux Tips for NetWare Administrators guide. 


+ Understand that in-house Linux expertise is a necessary prerequisite. (The good news is that fully 
89% of survey respondents who deployed OES discovered that they already had Linux expertise on 
their deployment teams.) 


For help, see Section 1.6, “How Much Training Is Needed?,” on page 20 and Section 1.7, “What 
Training Is Available?,” on page 21. 


Plan ahead and know your NetWare, OES, and eDirectory environments very well: 


+ Make sure eDirectory is clean and that you are current on all patches. 
+ Plan the deployment scenario and find the holes and gotchas. 
+ Plan data locations, file systems, and LUM configuration objects. 


+ Perform a complete inventory of all applications (and their dependencies) before you get too far into 
planning in case they or their dependencies can't be moved to OES/SLES. 


Upgrade slowly and cautiously, but start now 


+ Start at a small scale (a couple of servers) or just move DHCP for a couple of weeks, then DNS for 
a couple of weeks, then GroupWise, WebAccess, etc. 


+ Be careful; you can harm your production environment if you don't understand what you are doing; 
don't start with your most important servers. 


Test, test, test. 


¢ Test everything multiple times, including third-party products like backup solutions, before full 
deployment. 


+ Create an initial test box if you don't have previous Linux experience. 


+ Use VMware (or other virtualization products) and install many times to get the feel for it, then test, 
test, test. 


Give it a try. 
+ Moving to OES is easy and relatively painless. 
Start your upgrade in a lab environment first and play with the product. 


¢ Try installing Linux at home and use it as your primary OS. 


+ Make sure you have a test environment that mimics your production installation. 
It works the same as NetWare. 


+ The Novell management Interfaces look the same. iPrint, iManager, etc.—all of the benefits of 
NetWare are available on OES. 


Don't freak out about service and management differences 


Frequently Asked Questions 
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1.5 


1.5.1 


Customer Tip 


+ Learn the iMonitor and iManager Web tools for service and server management. 


+ Become familiar with the basic management commands, such as ndsconfig for eDirectory 
management. 


Do your homework and read everything you can find. 


+ Scour the discussion forums and see what problems others have had and how they solved them, 
ask questions, and make notes. 


Avoid mixing services on OES and NetWare, if possible. 


+ Create separate servers providing services such as DNS, DHCP, etc., on OES first to gain 
familiarity with Linux as a whole. 


YaST is your friend. 


+ This SLES management tool is not always the answer, though. Learn which things are best 
configured in the configuration files and which things you really should use YaST for. 


Find out how well your hardware vendor supports Linux. 


+ Make sure your hardware vendor not only “supports Linux,” but also provides regular driver updates 
for the version of SLES you are planning to deploy. 


What Are the Differences Between NetWare and 
OES? 


¢ Section 1.5.1, “System and Administrative User and Group Differences,” on page 12 
¢ Section 1.5.2, “Comparing Services Between NetWare and OES,” on page 13 
¢ Section 1.5.3, “Services Not Included in OES,” on page 20 


System and Administrative User and Group Differences 


Because OES services run on Linux rather than on NetWare, there are noticeable differences 
between the system and administrative users and groups on OES servers. For example, some OES 
services, such as Novell CIFS, require proxy users to retrieve service-related information and service 
attributes, and to write service information in eDirectory. 


For more information, see “System User and Group Management in OES 2015 SP1” and 
“Administrative Users and Groups in OES 2015 SP1” in the OES 2015 SP1: Planning and 
Implementation Guide. 
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1.5.2 


Comparing Services Between NetWare and OES 


Table 1-3 Service Comparison—NetWare 6.5 SP8 and OES 2015 SP1 


Service NetWare 6.5 
SP8 


Access Control Lists Yes 


AFP (Apple File Yes - NFAP 
Protocol) 


Apache Web Server Yes - NetWare 
port of open 
source product 


Archive and Version Yes 
Services (AVS) (Novell) 


Backup (SMS) Yes 


« SMS 
+ NSS-Xattr 


CIFS (Windows File Yes - NFAP 
Services) 


Clustering Yes 


DFS (Novell Distributed Yes 
File Services) 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Yes - Novell 
AFP 


Yes - Standard 
Linux 


No 


Yes 


Yes - Novell 
CIFS 


Yes 


Yes 


In combination with NCP Server, Linux supports 
the Novell trustee model for file access on NSS 
volumes and NCP (POSIX) volumes on Linux. 


AFP services on NetWare and OES are 
proprietary and tightly integrated with eDirectory 
and Novell Storage Services (NSS). 


“Using Apache HTTP Server on OES Servers 
(Single Server or Cluster Nodes)” in the OES 2015 
SP1: Web Services and Applications Guide. 


Administration Instance vs. Public Instance on 
NetWare. 


What's Different about Apache on NetWare. 


Discontinued from OES 2015. 


SMS provides backup applications with a 
framework to develop complete backup and 
restore solutions. For information, see the OES 
2015 SP1: Storage Management Services 
Administration Guide for Linux. 


NSS provides extended attribute handling options 
for NSS on Linux. For information, see “Using 
Extended Attributes (xAttr) Commands” in the 
OES 2015 SP1: NSS File System Administration 
Guide for Linux. 


Both NFAP and Novell CIFS are Novell proprietary 
and tightly integrated with eDirectory and Novell 
Storage Services (NSS). 


“Comparing Novell Cluster Services for Linux and 
NetWare” in the OES 2015 SP1: Novell Cluster 
Services NetWare to Linux Conversion Guide. 


In combination with NCP Server, DFS supports 
junctions and junction targets for NSS volumes on 
Linux and NetWare. 


DFS also supports junction targets for NCP 
volumes on non-NSS file systems, such as Btrfs, 
Ext3, and XFS. The VLDB command offers 
additional options to manage entries in the VLDB 
for NCP volumes. 
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Service 


DHCP 


DNS 


Dynamic Storage 
Technology (DST) 


eDirectory 8.8 


eDirectory Certificate 
Server 


eGuide (White Pages) 


Filr 


FTP Server 
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NetWare 6.5 
SP8 


Yes 


Yes 


No 


Yes 


Yes 


Yes 


No 


Yes 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Yes 


Yes 


Yes 


Yes 


No 


Entitlement 


Yes 


For a comparison between what is available on 
OES and NetWare, see “DHCP Differences 
Between NetWare and OES 2015 SP1” in the 
OES 2015 SP1: Planning and Implementation 
Guide. 


To plan your DHCP implementations, see 
“Planning a DHCP Strategy” in the OES 2015 
SP1: DNS/DHCP Services for Linux 
Administration Guide and “Planning a DHCP 
Strategy” in the NW 6.5 SP8: Novell DNS/DHCP 
Services Administration Guide. 


For a comparison between what is available on 
OES and NetWare, see “DNS Differences 
Between NetWare and OES 2015 SP1” in the 
OES 2015 SP1: Planning and Implementation 
Guide. 


See “Planning a DNS Strategy” in the OES 2015 
SP1: DNS/DHCP Services for Linux 
Administration Guide and “Planning a DNS 
Strategy” in the NW 6.5 SP8: Novell DNS/DHCP 
Services Administration Guide. 


For more information, see the OES 2015 SP1: 
Dynamic Storage Technology Administration 
Guide. 


No functional differences. 


No functional differences. 


This functionality is now part of the Identity 
Manager User Application. For more information, 
see the User Application: Administration Guide. 


See “Novell Filr’ on page 17. 


FTP file services on OES servers are provided by 
Pure-FTPd, a free (BSD), secure, production- 
quality and standard-conformant FTP server. The 
OES implementation includes support for FTP 
gateway functionality as on NetWare and offers a 
level of integration between eDirectory and Pure- 
FTP that allows users to authenticate to eDirectory 
for FTP access to the server. 


See “Novell FTP” in the OES 2015 SP1: Planning 
and Implementation Guide. 


Service 


Health Monitoring 
Services 


Identity Manager 4.0.2 
Bundled Edition 


iPrint 


IPX (Internetwork 
Packet Exchange) from 
Novell 


iSCSI 


KVM Virtualization 
Guest 


KVM Virtualization Host 
Server 


LDAP Server for 
eDirectory 


Multipath Device 
Management 


NetWare 6.5 
SP8 


Yes 


Yes 


Yes 


Yes 


No 


Yes 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Yes 


Yes 


No 


Yes 


Yes 


Yes 


Yes 


Yes 


In OES, NRM provides health monitoring via the 
open source monitoring tools Ganglia and Nagios. 
These tools do not use SFCB. 


For help with diagnosing problems using Ganglia 
and Nagios in OES, see “Diagnosing Problems 
Using Ganglia and Nagios (OES 2015 SP1)” in the 
OES 2015 SP1: Novell Remote Manager 
Administration Guide. 


The NRM Health Monitor tool is no longer 
available in OES 11 SP2 and later. 


For information about using Health Monitor in OES 
11 SP1 and earlier, see “Diagnosing Problems 
Using Health Monitor (OES 11 SP1)” in the OES 
2015 SP1: Novell Remote Manager Administration 
Guide. 


See “Using the Identity Manager 4.0.2 Bundle 
Edition.” (http://www.novell.com/documentation/ 
o0es2015/oes_implement_Ix/data/b143d3j6.html). 


See “ Overview” in the OES 2015 SP1: iPrint Linux 
Administration Guide, and “Overview” in the NW 
6.5 SP8: iPrint Administration Guide. 


No plans to port IPX to OES. 


The iSCSI target for Linux does not support 
eDirectory access controls like the NetWare target 
does. Nor is the iSCSI initiator or target in OES 
integrated with NetWare Remote Manager 
management. You use YaST management tools 
instead. 


On the other hand, the iSCSI implementation for 
Linux is newer and performs better. 


See Linux-iSCSI Project on the Web (http://linux- 
iscsi.sourceforge.net). 


See “Overview” in the NW 6.5 SP8: iSCSI 1.1.3 
Administration Guide. 


Of the two OES virtualization solutions (KVM and 
Xen), only Xen is supported for running Netware. 


No functional differences. 


No functional differences. 


NetWare uses NSS multipath I/O. Linux uses 
Device Mapper - Multipath that runs underneath 
other device management services. 
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Service 


MySQL 


NCP Volumes 


NCP Server 


NetStorage 


NetWare Traditional 
File System 


NetWare Traditional 
Volumes 


NFARM 


NFS 


NICI (Novell 
International 
Cryptography 
Infrastructure) 


NetWare 6.5 
SP8 


Yes - NetWare 
port of open 
source product 


No 


Yes 


Yes 


Yes 


Yes 


No 


Yes - NFAP 


Yes 


OES 2015 SP1 


Yes - Standard 
Linux 


Yes 


Yes 


Yes 


No 


N/A 


Yes 


Yes - native to 
Linux 


Yes 
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Platform Differences / Migration Issues 


See MySQL.com on the Web (http:// 
www.mysql.com). 


See “Overview: MySQL” in the NW 6.5 SP8: 
Novell MySQL Administration Guide. 


See also “Configuring MySQL with Novell Cluster 
Services” in the OES 2015 SP1: Web Services 
and Applications Guide. 


NCP Server on Linux supports creating NCP 
volumes on Linux POSIX file systems such as 
btrfs, Reiser, Ext2, Ext3, and XFS. 


OES includes support for much larger NCP 
volumes. 


For information, see “Managing NCP Volumes” in 
the OES 2015 SP1: NCP Server for Linux 
Administration Guide. 


NCP services are native to NetWare 6.5 and NSS 
volumes; to have NCP services on OES, the NCP 
Server must be installed. 


See “Benefits of NCP Server” in the OES 2015 
SP1: NCP Server for Linux Administration Guide. 


NetStorage on Linux offers connectivity to storage 
locations through the CIFS, NCP, and SSH 
protocols. NetWare uses only NCP. 


No plans to port the NetWare Traditional File 
System to Linux. 


The Novell Access Rights Management (NFARM) 
shell extension for Windows Explorer lets you 
manage Novell Trustee ACLs for AD users and 
groups who have access to AD-enabled NSS 
volumes. 


For more information, see “Managing the Rights of 
Active Directory Users Using NFARM’in the OES 
2015 SP1: NSS AD Deployment and 
Administration Guide. 


For NetWare, see “Working with UNIX Machines” 
in the NW 6.5 SP8: AFP, CIFS, and NFS (NFAP) 
Administration Guide. 


No functional differences. 


Service 


NIT 


NMAS (Novell Modular 
Authentication 
Services) 


Novell Audit 


Novell Client for 
Windows and Linux 
support 


Novell Cluster Services 
(NCS) 


Novell Filr 


Novell iFolder 2.x 


Novell iFolder 3.9 


Novell Licensing 
Services 


Novell Linux Volume 
Manager 


NetWare 6.5 
SP8 


No 


Yes 


Yes 


Yes 


Yes 


No 


Yes 


No 


Yes 


No 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Yes 


No 


Yes 


Yes 


Yes 


No 


Yes 


No 


Yes 


The Novell Identity Translator provides UID 
support for eDirectory and Active Directory users 
accessing NSS data through CIFS. 


For more information, see “NIT (Novell Identity 
Translator)”in the OES 2015 SP1: NSS AD 
Deployment and Administration Guide 


No functional differences. 


Novell Audit is not included with OES. However, 
the Novell Audit 2.0 Starter pack is available for 
download at no cost on Novell.com (http:// 
www.novell.com/downloads). 


Novell Client connectivity to OES requires that the 
NCP Server be installed. 


Access to the larger NCP volumes supported by 
OES requires the latest Novell Client software. 


See “Product Features” in the OES 2015 SP1: 
Novell Cluster Services for Linux Administration 
Guide. 


See “Product Features” in the NW6.5 SP8: Novell 
Cluster Services 1.8.5 Administration Guide. 


Organizations with a current maintenance 
agreement are entitled to deploy Novell Filr at no 
cost. 


For more information, see the Novell website. 


Filr supports NSS-AD integration in OES 2015 or 
later. 


For migration information, see “Migrating iFolder 
2.x” in the OES 2015 SP1: Migration Tool 
Administration Guide 


OES includes Linux, Macintosh, and Windows 
clients. 


See OES Doesn't Support NLS in the OES 2015 
SP1: Planning and Implementation Guide. 


The Novell Linux Volume Manager (NLVM) 
command line interface can be used to create and 
manage Linux POSIX file systems. 


For information about the syntax and options for 
the NLVM commands used in this section, see the 
OES 2015 SP1: NLVM Reference. 
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Service 


NSS (Novell Storage 


Services) 


NTPv3 


OpenSSH 


PAM (Pluggable 
Authentication 
Modules) 


Pervasive.SQL 


PKI (Public Key 
Infrastructure) 


Printing 
QuickFinder 
RADIUS 


Salvage 


Samba 


Search (QuickFinder) 


NetWare 6.5 
SP8 


Yes 


Yes 


Yes 


No 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


No 


Yes 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes 


Yes 


Yes 


Yes 


No 


Yes 


Yes 


No 


Yes 


Yes 


Yes 


No 
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Most NSS services are available on both 
platforms. For a list of NSS features that are not 
used on Linux, see “Cross-Platform Issues for 
NSS” in the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


In OES 11 and later, NSS supports both the DOS 
and GPT partitioning scheme. 


In OES 11 SP1 and later, NSSMU supports Linux 
volumes in addition to NSS pools and volumes. 


The ntpd.conf file on NetWare can replace an 
OES server’s NTP configuration file without 
modification. 


NetWare includes a port of the open source 
product. Linux includes the open source product 
itself. 


See “Functions Unique to the NetWare Platform” 
in the NW 6.5 SP8: OpenSSH Administration 
Guide. 


PAM is a Linux service that Novell leverages to 
provide eDirectory authentication. eDirectory 
authentication is native on NetWare. 


Pervasive.SQL is available for Linux from the Web 
(http://www.pervasive.com). 


No functional differences. 


See iPrint. 
See Search. 


See the information on forge.novell.com (http:// 
forge.novell.com/modules/xfmod/project/ 
?edirfreeradius). 


Salvage is now supported for eDirectory and AD 
users using NFARM utility. 


Samba is an open source technology available on 
OES. Novell provides automatic configuration for 
authentication through eDirectory. For more 
information, see the OES 2015 SP1: Novell 
Samba Administration Guide. 


Discontinued from OES 2015. 


Service NetWare 6.5 
SP8 

SLP Yes - Novell 
SLP 


Software RAIDS (NSS Yes (0, 1,5,01, Yes (0,1,5,0 


volumes) 51) 


Storage Management Yes 
Services (SMS) 


TCP/IP Yes 
Timesync NLM Yes 
Tomcat Yes 
Virtual Office Yes 


(Collaboration) 


WAN Traffic Manager Yes 


Xen Virtualization Yes 
Guest 


Xen Virtualization Host N/A 
Server 


OES 2015 SP1 Platform Differences / Migration Issues 


Yes - 
OpenSLP 


1,51) 


Yes 


Yes 


No 


Yes 


No 


No 


Yes 


Yes 


For OES, see SLP in the OES 2015 SP1: Planning 
and Implementation Guide. 


NetWare uses Novell SLP, which provides caching 
of Directory Agent scope information in eDirectory. 
This provides for sharing of scope information 
among DAs. 


OpenSLP on Linux is customized to provide DA 
information retention and sharing as well. 


See “Understanding Software RAID Devices” in 
the OES 2015 SP1: NSS File System 
Administration Guide for Linux. 


The SBCON backup engine is not supported on 
Linux. 


The nbackup engine is available for exploring 
SMS capabilities, but in a production environment, 
you should use a third-party, full-featured backup 
engine. 


Beginning with OES 2015, SMS is enhanced to 
support the 64-bit storage enhancements and AD- 
user ACLs on AD-enabled NSS volumes. 


No functional differences. 


Timesync will not be ported to Linux. However, 
NTPv3 is available on both Linux and NetWare. 


See Time Services in the OES 2015 SP1: 
Planning and Implementation Guide. 


NetWare includes Tomcat 4 and a Tomcat 5 
servlet container for iManager 2.7. OES includes 
Tomcat 6. There is no impact to any of the 
administration tools, which are tested and 
supported on both platforms. 


See “Administration Instance vs. Public Instance 
on NetWare” 


Virtual Office has been replaced by Novell Vibe A 
separate purchase is required. For more 
information, see the Novell Vibe website (https:// 
www.novell.com/products/vibe/). 


NetWare 6.5 SP8 (and NetWare 6.5 SP 7) can run 
as a paravirtualized machine. OES can run as a 
paravirtualized machine or fully virtualized 
machine. 
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1.5.3 


1.6 


1.6.1 


1.6.2 


Services Not Included in OES 


See “eGuide, IFolder 2, and Virtual Office Are Still Available on Netware” in the NW 6.5 SP8: Planning 
and Implementation Guide. 


How Much Training Is Needed? 


¢ Section 1.6.1, “What Our Customers Tell Us,” on page 20 
¢ Section 1.6.2, “Conduct a Training Assessment,” on page 20 


What Our Customers Tell Us 


Some customers have found that their administrators need Linux training. Novell provides several 
training courses to help bring administers up to speed with administering OES services on Linux. 
Familiar tools, such as iManager and Novell Remote Manager (NRM), and utilities such as NSSMU 
and NLVM are also used to administer Novell services on OES. Many administrators are pleasantly 
surprised when they see that their knowledge and skills apply very well to managing Novell services 
on OES. 


We recognize that time and resources are a problem for customers, and we recommend following the 
example of one of our customers: Four months prior to rollout, Novell provided OES and SLES 
training for their administrators at their site and on their hardware and software. 


When we survey customers, they consistently tell us they want training that addresses: 


¢ Differences in day-to-day support and management versus NetWare 
¢ How to install and upgrade existing NetWare servers to OES 
¢ Differences between NetWare and OES: services, features, and interoperability 


¢ Troubleshooting 


Conduct a Training Assessment 


Novell recommends that you conduct a training needs assessment. You should determine whether 
current skill sets are absent, adequate, or proficient, so that you can recommend a training package. 
Three levels of Linux expertise are recommended: 


Table 1-4 Recommended Linux Training Levels 


Level of Expertise Training Needed Qualities of Potential Candidates 
Certified Linux Expert You will probably want at least some of + Are typically already UNIX (AIX, 
your technical staff to be Linux certified Solaris, etc.) experts. 


(LPI level1 and/or LPI level 2). Many 

third-party Linux certification courses are 

available to meet this need. + Are willing to attend additional class 
and lab sessions. 


+ Have some Linux experience. 


+ Are willing to serve as trainers and 
mentors. 


+ Have accredited certifications. 
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1.7 


1.7.1 


1.7.2 


Level of Expertise 


Linux Administrator 


Training Needed 


Novell recommends SUSE Linux-specific 
training. 


Novell offers a variety of instructor-led 
and self-study certification and training 
options including Novell Advanced 
Technical Training (ATT), which is highly 
recommend. 


The comprehensive courses address a 
wide range of advanced topics including 
support issues, in-depth architectural 
reviews, and enterprise solutions. ATT 
classes provide real-world expertise that 
can be put to immediate use. 


Qualities of Potential Candidates 


+ Are currently UNIX or NetWare 
administrators who are willing to 
expand skills 


+ Have data center and server farm 
administrative experience. Deep 
technical skills are less important. 


+ Have expertise in services above 
the OS level. OS knowledge is 
necessary. 


Linux Support Staff 


Support staff need to be knowledgeable 
about how specific network services 
(eDirectory, edge services, iPrint, etc.) 
work on Linux. 


Novell offers service-specific courses for 
most major services. 


What Training Is Available? 


Here are some of the avenues you can use to get the training you need: 


¢ Section 1.7.1, “Novell Training Services,” on page 21 


+ Support current file, print, and other 
network systems. 


+ Will need to move to more Linux 
support, but system focus will 
remain the same. 


¢ Section 1.7.2, “Complimentary Free Training,” on page 21 


¢ Section 1.7.3, “Product Documentation,” on page 22 


Novell Training Services 


Novell certification and training options change periodically as new needs are identified and courses 
are developed. To learn more about these and other training options, visit the OES Novell training 
Web site at www.novell.com/training (http://www.novell.com/training/courseware/ 


catalog.jsp?pl=7660). 


¢ To find the dates and local availability of the Novell Advanced Technical Training and other 
Novell offerings, go to: www.novell.com/training/pep/map.html (http://www.novell.com/training/ 


att/map.html). 


+ To request additional information on Novell Advanced Technical Training, send an e-mail to 
technicaltraining @novell.com (mailto:technicaltraining@novell.com) 


¢ To subscribe to the Technical Training Newsletter, see http://www.novell.com/info/list (http:// 


www.novell.com/company/subscribe/) 


Complimentary Free Training 


To help you get started with OES and Linux, Novell provides some training material at no cost on the 
Web (http:/Awww.novell.com/training/complimentary/). See the topics under Novell Technical Training. 
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1.7.3 


1.8 


Product Documentation 


Yes, the old adage is true: “If all else fails, read the documentation.” This document contains 
numerous cross-references to sections relative to a specific topic or service. If you can't find what you 
need on Novell's documentation site, add a comment, tell us what we missed, and we'll see that you 
get the answer you need. Open Enterprise Server 11 documentation is available at the following URL: 
http://www.novell.com/documentation/oes11/index.html (http:/Awww.novell.com/documentation/ 
oesi11/index.html). 


One especially useful guide for those who are transitioning from NetWare to OES and Linux is the 
OES 2015 SP1: Linux Tips for NetWare Administrators guide. 


SuSE publishes all of the SLES 11 documentation on the Web (http://www.suse.com/documentation/ 
sles11/index.html). 


Does Novell Have Community Support to Help Me 
with My Migration? 
There are a two good places to connect with other administrators, ask questions, and find answers to 
your specific migration questions. 

+ Novell Forums (http://forums.novell.com/) 

¢ Cool Solutions Upgrade to OES Community Page (http://Awww.novell.com/communities/ 


coolsolutions/upgradetooes) 


There is a list of the top TIDs (http:/Awww.novell.com/communities/node/8781/top-oes-upgrade-tids) 
to help you troubleshoot and deal with migration issues. 


Finally, you can get OES information from Twitter by following NovellOES (http://www.twitter.com/ 
novelloes), and there’s a FaceBook Page (http://www.facebook.com/ 
desktopapp.php?api_key=97e8a45d27cbe2bd96a95/cb9cd22f10#/pages/|-Upgraded-to-Novell- 
Open-Enterprise-Server-on-SUSE-Linux-Enterprise/154405544072?ref=ts) as well. 
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2.1 


2.1.1 


2.1.2 


Getting Started 


You can ensure a successful upgrade by 


¢ Section 2.1, “Assessing Your Current Network,” on page 23 


¢ Section 2.2, “Identifying Needed Improvements,” on page 25 


Assessing Your Current Network 


¢ Section 2.1.1, “Running Novell Support Advisor,” on page 23 
¢ Section 2.1.2, “Recording Your Current Network Information,” on page 23 


Running Novell Support Advisor 


To ensure you are equipped with the latest pre-upgrade information and area aware of known issues, 
we recommend you validate your OES upgrade readiness using the Novell Support Advisor 1.1 (or 
later) tool. For more information and to obtain this free tool, access the Novell Support Advisor Web 
page (http://support.novell.com/advisor). 


Recording Your Current Network Information 


Whether you will be upgrading on your own, using Novell Global Services, or working with another 
consulting firm, you need a complete and accurate record of your current network setup. 


1 If you don’t already have one, create one or more diagrams of your network, including the 
following information: 


+ Router/switch/subnet/firewall diagrams; note particularly any blocked ports 


+ Current WAN configuration, including link speeds for all sites running NetWare. Duplicate 
the following tables or use a spreadsheet, as necessary, to accommodate multiple sites. 


Table 2-1 Sample WAN Environment Overview 


Site Location WAN Speed # of Servers Server Breakdown 


Home Office Local 25 3-NW4.11 
3-NW5.0 
4-NW5.1 
3-NW6.0 
3-NW6.5 
5-W2K3 
2-W2K 
2-RHEL3 
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Site Location WAN Speed # of Servers Server Breakdown 


Table 2-2 Sample WAN Location Environment Overview 


Site # of NetWare Server Notes # of Client Client Notes 
Location NetWar Versions Client Breakdown 
e s 
Servers 
Southwest 6 2-NW4.11 All NetWare are 30 4—Win98 Win9x clients will 
Office 1-NW5.1 being retired. 6-W2K be migrated to 
3-NW6.5 Users will be 20-WinXP Windows XP 
moved to OES Professional SP2 
servers 


If you don’t already have a current directory design document, create one that includes: 
+ NDS/eDirectory tree diagrams. 
¢ Partition and replication diagrams. 
+ NDS versions, such as NDS v6, v7, and/or v8. 
¢ Versions of NDS/eDirectory that are installed on non-NetWare operating systems. 


+ Other Novell applications that are directly dependent on eDirectory, such as Novell Account 
Management, DirXML, and Identity Manager. 


+ Any bindery contexts currently in use, including a brief description of how they are used. 


List all of the NetWare servers in your tree along with their context, IP address information, and 
any other information you might need as you plan to migrate them. 


4 Identify any NetWare traditional (non-NSS) volumes being used on your NetWare servers. 


5 Identify the file services provided by NetWare servers, including AFP, CIFS, iFolder, NetStorage, 


10 


FTP, and NCP (Novell Client), then list the servers that provide them and the contexts of the 
users that use them. 


Identify the printers that are serviced by NetWare servers, along with the print services 
associated with them, including iPrint, NDPS-based printing, and legacy queue-based printing. 


Identify any in-house applications developed specifically for NetWare and briefly describe the 
services that these provide. 


Identify other Novell products, such as GroupWise, ZENWorks, or Identity Manager that are 
currently running on NetWare, and verify which of these are supported on OES. 


Document how your e-mail infrastructure is currently set up. 


Identify any third-party applications currently running on the NetWare servers, such as backup/ 
restore and anti-virus solutions. 


Verify with the vendors whether these applications are supported on SLES 11/OES and whether 
they are Novell YES Approved. 


Specify which applications will be ported to OES and which must continue to run on NetWare for 
the time being. 
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2.2 


2.2.1 


11 List any databases (critical or otherwise) that are stored on NetWare servers. 


12 Create a design document that outlines your network service configurations, including time 
synchronization, SLP, DNS, DHCP, and any other network protocols or services that might be 
impacted by an upgrade to OES, such as IPX. 


13 Collect any standards documents you have, such as server standards and naming standards. 


14 Collect or document the hardware information for your NetWare servers, including processor 
specs, RAM configuration and storage adapters. 


15 Document any NetWare clusters in your network, both Novell Clustering Services (NCS) clusters 
and Business Continuity Clustering (BCC) clusters. Specify the function of each cluster node, 
including service failover configurations. 


16 Specify any security standards that must be met on OES/Linux. Unlike NetWare, Linux security 
is much more modular/granular. 


The tables in the next section suggest additional information you might need to collect before you 
begin planning your upgrade to OES. 


Identifying Needed Improvements 


¢ Section 2.2.1, “Server Hardware Considerations,” on page 25 

¢ Section 2.2.2, “Consolidation Considerations,” on page 26 

¢ Section 2.2.3, “Virtualization Considerations,” on page 27 

¢ Section 2.2.4, “File System Considerations,” on page 27 

¢ Section 2.2.5, “Method Considerations,” on page 27 

¢ Section 2.2.6, “Network Considerations,” on page 27 

¢ Section 2.2.7, “eDirectory/LDAP Considerations,” on page 28 

¢ Section 2.2.8, “Time Synchronization,” on page 28 

¢ Section 2.2.9, “Cluster Considerations,” on page 28 

¢ Section 2.2.10, “Application Compatibility Considerations,” on page 29 
¢ Section 2.2.11, “LAN/WAN Connection Considerations,” on page 29 


Server Hardware Considerations 


How is your server hardware holding up? Do you need to invest in some new hardware for the 
upgrade to OES to succeed? 


Many customers tell us that choosing the right hardware is not a straightforward task. 


Your best bet is to start with the Novell OES Partner Products page (http:/Awww.novell.com/ 
partnerguide/section/677.html). 


If you don’t already have an agreement with a hardware vendor, all Novell Partners deserve 
consideration. Be sure to communicate with your chosen hardware vendors regarding server sizing 
guidelines to ensure that you select the right server and hardware configuration. 


Table 2-3 outlines both “minimum” and “recommended” requirements for running OES. 


NOTE: The RAM and disk space amounts shown in Table 2-3 are for system components only. The 
OES components you install might require additional RAM and disk space. 
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Table 2-3 Minimum and Recommended Hardware Requirements 


System Minimum Recommended 
Compone 
nt 


Computer Server-class computer Server-class computer that has been certified by the hardware 
with an AMD64/Intel vendor for SLES 11 SP4. 
EMG64T processor. 


Memory 1 GB of RAM 2 GB of RAM 

Free Disk 7 GB of available, 10 GB of available, unpartitioned disk space. Additional disk 

Space unpartitioned disk space might be required depending on which OES components 
space. are selected and how they are used. 


DVD Drive DVD drive if installing 48X DVD drive if installing from physical media. 
from physical media 


Network Ethernet 100 Mbps 


Board 
Storage N/A When determining what hardware bus adapters (HBAs) to use for 
Adapter SAN-attached OES servers, take all of the software and 


hardware components into account. Linux drivers are available 
for almost all enterprise-class HBAs and many of them are OES 
certified. 


However, hardware vendors tend to be more restrictive with 
certification than the operating system is. Any HBA used with 
OES must be certified by both the storage vendor for a specific 
model as well as the Fibre Channel switch vendor. 


IP Address + One IP address on Internet connectivity from the server in order to complete 
a subnet registration and configure patches 


+ Subnet mask 


+ Default gateway 


Mouse N/A USB or PS/2 
Server If you are doing a DVD 

Computer installation, prepare the 

BIOS BIOS on your server 


computer so that it boots 
from the CD-ROM/DVD 
drive first. 


Consolidation Considerations 


This might be a good time to consider taking advantage of today's more powerful hardware platforms 
and doing some server consolidation. Server consolidation often pays off in lower hardware costs, as 
well as lower cooling, power consumption, and rack space costs. For example, Novell consolidated 
fourteen older file and print servers to two new servers. 


Which combinations of eDirectory, file, print, GroupWise, etc., might reasonably work together on the 
same host server? 
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2.2.9 


2.2.6 


Virtualization Considerations 


To help with the transition from NetWare to OES, virtualization has been optimized so that you can 
run NetWare 6.5. SP7 and later as a paravirtualized guest operating system on OES servers. 


Doing this provides another option for running NetWare-dependent applications and services. For 
example, most third-party NLM software can be accommodated this way until suitable alternatives 
can be developed for Linux. 


Which NetWare-dependent applications and services will you need to run on an interim basis as part 
of your transition to OES? Will virtualization help with this? 


Installing Hosts: For information about installing a virtual machine host and setting up virtual 
machines in general, see Virtualization with Xen (http://www.suse.com/documentation/sles11/ 
book_xen/data/book_xen.html), particularly “Setting Up Virtual Machines” (http://www.suse.com/ 
documentation/sles11/book_xen/data/cha_xen_vm.html). 


Installing Guest Operating Systems: For information about installing NetWare as a guest operating 
system, see “Installing and Managing NetWare on a Xen-based VM” in the OES 2015 SP1: 
Installation Guide. For information about installing OES as a guest operating system, “Installing, 
Upgrading, or Updating OES on a VM" in the OES 2015 SP1: Installation Guide. 


File System Considerations 


Which file system should be used: Linux traditional volumes (Ext3, Btrfs, XFS), NSS, or another file 
system? 


+ Does it make sense to have different servers using different file systems depending on the 
server's primary role? 
+ Are you already using Novell Storage Services (NSS) volumes on NetWare? 


If so, you should probably preserve all the rights, metadata, and trustee information associated 
with the data on those volumes, so it makes sense to stay with Novell Storage Services. 


+ Are your volumes already in a SAN environment with NSS? 


If so, switching to a SAN environment that uses NSS on Linux is quite easy. Using DFS junctions 
also requires NSS to support volume moves and splits. And if business continuity clusters are in 
your plans, you might find them easier to implement if you're using NSS. 


NOTE: For GroupWise under Linux, the recommended file system for GW2012 is ext3 (http:// 
www.novell.com/documentation/groupwise2012/gw2012_guide_install/data/ 
b3kipez.html#b77qw4a). 


Method Considerations 


Which of the various tools best meets your needs? Knowing which tools you will use is important to 
planning your upgrade strategy. 


Network Considerations 


Is the network functioning optimally, or do you need to make changes before you upgrade? 


Are required ports available? 
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Make sure that services such as DNS, DHCP, and SLP are optimally configured and in good working 
order. This is critical for all installations and upgrades. 


2.2.7 eDirectory/LDAP Considerations 


Is the eDirectory partition and replication layout optimal: 


+ Where are the replica rings located? 
¢ Which servers have partitions on them? 
+ Where do your want replication rings and partitions to be after you finish your upgrade to OES? 


If you fail to plan properly in this area, you can count on running into network replication 
problems. Refer to the NetIQ eDirectory 8.8 SP8 Administration Guide, particularly “Designing 
Your NetIQ eDirectory Network” for detailed information. 


¢ If your current eDirectory tree structure doesn’t meet your needs, is it time to redesign it? 


Novell recommends implementing multiple LDAP servers because of the critical nature of the LDAP 
service. LDAP servers should be fronted with an L4 switch for load sharing and redundancy. If an L4 
switch is not available, then DNS round-robin could be used as an alternative. 


2.2.8 Time Synchronization 


Is time synchronization on your network in order? 


+ Are all NetWare virtual machines using Timesync rather than NTP? 
¢ Is the TCP/IP protocol loaded on any physical NetWare servers that use NTP? 
¢ Is only one server used as the ultimate time source? 


NTP uses a time provider group in which all servers in a geographical network obtain time from 
other servers in the same network. Only one network server should communicate with a server 
outside the network in order to keep traffic across routers and WANs at a minimum. 


To understand time synchronization requirements and possibilities in an OES network, see “Time 
Services” in the OES 2015 SP1: Planning and Implementation Guide. 


2.2.9 Cluster Considerations 


If clusters are part of your plan, how will your cluster environment impact your efforts to upgrade to 
OES? 


+ What is the primary role of your cluster (GroupWise high availability, file and print services, 
directory services)? 


+ Do you need to consider splitting large clusters into multiple smaller clusters, one for each 
service? 


By separating clusters this way, problems in one service cluster won't spill over and potentially 
affect other clustered services. 


Splitting your clusters can also simplify administration efforts, because you can independently 
manage each cluster. Also, if you need to do a cluster update, a rolling upgrade of a six-node 
cluster is much easier than a rolling upgrade of a 32-node cluster. 
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2.2.11 


+ Are you planning to implement Novell Business Continuity Clustering to allow automated 
management of site-to-site failovers? If so, how will this affect your efforts and will your network 
topology be affected? Business Continuity Clustering lets you define which of your resources are 
considered “vital,” so only those services move to an off-site location rather than the entire 
cluster. 


¢ Will a rolling upgrade help you upgrade your clustered services? 


Refer to the “Converting NetWare Cluster Nodes to OES (Rolling Cluster Conversion)” in the 
OES 2015 SP1: Novell Cluster Services NetWare to Linux Conversion Guide for detailed 
information. 


Application Compatibility Considerations 


What applications are currently hosted on your NetWare servers? Are comparable Linux applications 
available and are they certified for OES or SLES. 


Because of the multitude of applications being used by our customers, it is impossible for Novell to 
make recommendations in every instance, so you might need to contact the vendor directly. But first 
check the Novell Partner Products site (http://www.novell.com/partnerguide/section/677.html) for the 
latest certifications. 


LAN/WAN Connection Considerations 


Is the performance of all of your WAN links within acceptable limits? Are there any indications of 
systemic problems? Are all replica rings maintaining proper synchronization? 


It is essential that all of your LAN/WAN connections be performing within the expected parameters 
before you begin your upgrade to OES. 
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3.1 


3.1.1 


Upgrading eDirectory to OES 


This section discusses upgrading eDirectory to OES and includes the following sections: 


¢ Section 3.1, “About eDirectory in OES,” on page 31 

¢ Section 3.2, “Planning Your eDirectory Upgrade,” on page 34 

¢ Section 3.3, “Upgrading eDirectory,” on page 37 

¢ Section 3.4, “Post-Upgrade Checks,” on page 40 

¢ Section 3.5, “About Domain Services for Windows,” on page 40 


¢ Section 3.6, “Additional eDirectory Resources,” on page 43 


About eDirectory in OES 


¢ Section 3.1.1, “The Role of eDirectory in OES,” on page 31 
¢ Section 3.1.2, “eDirectory Version Considerations,” on page 32 


¢ Section 3.1.3, “About eDirectory Management Tools in OES,” on page 33 


The Role of eDirectory in OES 


+ “eDirectory Is Essential to OES Services” on page 31 
+ “About Installing eDirectory and OES Services” on page 31 
+ “The First Server Is Critical” on page 32 


+ “eDirectory Provides Additional Security for the Server” on page 32 


eDirectory Is Essential to OES Services 


eDirectory is an integral component of the services that make up OES. As with NetWare, service 
users are created as User objects in eDirectory and authenticate to gain service access. 


OES servers exist as Server objects and there are numerous other objects and configurations stored 
“behind the scenes” in eDirectory that work together to deliver the same functionality that people are 
accustomed to with NetWare. 


eDirectory even provides eDirectory users with access to some services that would normally require 
the creation of local user accounts on the server itself. 


About Installing eDirectory and OES Services 


During the install, when you reach the software selections screens, none of the OES services is 
selected by default. 


You can specifically select eDirectory for installation, or, if you select a service that requires 
eDirectory, eDirectory is automatically selected for installation. 
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If you are installing into an existing eDirectory tree and you don’t want eDirectory installed on the 
server, you can deselect it. 


When you configure the services that require eDirectory, you enter the information for an eDirectory 
server in the tree (either the server you are installing or an existing server), including the name, 
context, and password of an administrative user with rights to install the required objects in the tree. 


The First Server Is Critical 


If you are creating a new eDirectory tree on your network, the first server you install is important for 
two reasons: 


+ The basic eDirectory tree structure is created during the first installation. 


+ The first server permanently hosts the Certificate Authority for your organization. 


eDirectory Provides Additional Security for the Server 


When you install eDirectory on a server, the server is configured by default to use eDirectory 
certificates for HTTPS services, providing a significantly enhanced level of security for the server. 


For more information, see “Certificate Management” in the OES 2015 SP1: Planning and 
Implementation Guide. 


eDirectory Version Considerations 


Novell recommends that all servers in a tree be of the same fully supported eDirectory and OS 
versions. 


¢ “eDirectory 8.8.8” on page 32 
¢ “eDirectory 8.7.3 on NetWare 6.5 SP8” on page 32 
¢ “Migrating Earlier DS Versions” on page 32 


eDirectory 8.8.8 


OES includes eDirectory 8.8.8. Where possible, you should upgrade existing servers to eDirectory 
8.8.8 before or during the process of introducing OES into the environment. 


For complete information, refer to the NetIQ eDirectory 8.8 SP8 What’s New Guide available at 
www.novell.com/documentation/edir88 (http://www.novell.com/documentation/edir88/). 


eDirectory 8.7.3 on NetWare 6.5 SP8 


Novell supports eDirectory 8.7.3.9 or later on NetWare to facilitate the transition from NetWare to 
OES. Although they have somewhat different feature sets, these two versions of eDirectory are 
tested and certified to inter-operate within the same tree. 


eDirectory must be hosted on a current fully supported OS. At this time, the only version of NetWare 
that is under support is NetWare 6.5, which is under extended support. 


Migrating Earlier DS Versions 


Earlier versions of DS/eDirectory should be migrated to eDirectory 8.7.3.7 as outlined in Table 1-1, 
“Upgrade Paths from Earlier Versions of NetWare,” on page 10. 
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3.1.3 About eDirectory Management Tools in OES 


Several tools, many of them Web-based, can be used to manage aspects of eDirectory. The primary 
tools are listed here. 


+ iManager 2.7: A browser-based tool that lets you set up and manage your NetIQ eDirectory 
tree; manage eDirectory objects, schema, partitions, and replicas; and create and manage 
users, groups, and other objects. For more information, see NetlQ® iManager Administration 
Guide. 


+ iMonitor: A browser-based tool that provides cross-platform monitoring and diagnostic 
capability for all servers in an eDirectory tree. For more information, see “Using NetIQ iMonitor” 
in the NetIQ eDirectory 8.8 SP8 Administration Guide. 


+ Novell Remote Manager for OES: A browser-based utility for monitoring server health, 
changing the server configuration, or performing diagnostic and debugging tasks. Novell Remote 
Manager (NRM) provides functionality that is not available in other management utilities. For 
information, see the OES 2015 SP1: Novell Remote Manager Administration Guide. 


+ Novell Import Conversion Export Utility (ICE): You use ICE to: 
+ Import data from LDIF files to an LDAP directory 
+ Export data from the LDAP directory to an LDIF file 
+ Move data between LDAP servers 
+ Perform a schema compare and update 
+ Load information into eDirectory by using a template 
+ Import schema from SCH files to an LDAP directory 


For more information, see “NetIQ Import Conversion Export Utility” in the NetIQ eDirectory 8.8 
SP8 Administration Guide. 


¢ DSBK: This is a thin command line parser that performs the same operations as the Backup 
eMTool, but it lets you initiate a backup from the server console without logging in first or setting 
up Role-Based Services. 


For more information, see “Using DSBK ” in the NetIQ eDirectory 8.8 SP8 Administration Guide. 


+ 


eDirectory Management Toolbox (eMBox): Lets you access all of the eDirectory back-end 
utilities remotely or on the server and works with Novell iManager to provide Web-based access 
to eDirectory utilities such as DSRepair, DSMerge, and Service Manager. 


For more information, see “The eDirectory Management Toolbox” in the NetiQ eDirectory 8.8 
SP8 Administration Guide. 


¢ Terminal Prompt Configuration Tools. The following tools are also available: 


+ ndsconfig: Lets you configure eDirectory, add an eDirectory replica server to an existing 
tree, or create a new tree. For usage information, enter man ndsconfig at the terminal 
prompt. 

Idapconfig: On OES servers, only use this when explicitly instructed to in the OES-specific 
documentation. 


nmasinst: Lets you configure Novell Modular Authentication Service (NMAS) and install 
login methods. For usage information, enter man nmasinst at the terminal prompt. 


General Utilities. Refer to “NetIQ eDirectory Linux Commands and Usage” in the NetIQ 
eDirectory 8.8 SP8 Administration Guide for a list and description of command line tools 
along with syntax, and refer to “_DAP-Specific Commands” for LDAP-specific commands. 


+ ConsoleOne: This utility is not supported to perform administration tasks on OES server. 
However, if you have a service that requires ConsoleOne, such as Novell GroupWise, it is 
supported for administration of those applications. 
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3.2 Planning Your eDirectory Upgrade 


Installing eDirectory on OES provides an excellent opportunity to review your current directory 
structure to ensure that it meets your organization's needs and growth patterns. 

¢ Section 3.2.1, “Deciding Whether to Redesign Your Tree,” on page 34 

è Section 3.2.2, “Checking eDirectory Health,” on page 35 


¢ Section 3.2.3, “For More Information,” on page 37 


3.2.1 Deciding Whether to Redesign Your Tree 


Upgrading to OES provides an excellent opportunity to evaluate whether changes are necessary to 
better accommodate your current and future needs. 

+ “Questions to Ask” on page 34 

+ “Deciding Whether to Move Services” on page 35 

¢ “For File and Print, Design around Your WAN” on page 35 

+ “Verify Your Redesign in a Lab First” on page 35 


Questions to Ask 


+ Type of Tree: Does a Traditional (pyramid-shaped, single tree environment) or specialized tree 
(flat tree designed for a specific situation such as an identity vault or LDAP authentication) make 
better sense in your environment? Many Novell customers are opting for a flat tree so LDAP can 
walk the tree more efficiently to find a user object. 


+ Physical Network Layout—Location-based and Designed Around WAN links): Analyze the 
number of offices, where they are located, how many users are at each site, how sites 
communicate with each other, whether offices share the same data, and how data is routed 
among the sites. 


+ 


Organizational Structure—Function-based Design): Is your organization static or dynamic? 
What growth patterns do you anticipate? 


+ 


Security: How secure does your data need to be? Does some data need enhanced security? 


¢ Server configuration: What types of servers are on your network? Do they need to interact? 
Where are they located? What applications and services does each host? Are they managed 
locally or centrally? 


¢ User accessibility needs: Which applications and services are needed by which users? Do 
users need to read data or modify it? which rights need to flow from the root? How many users 
need remote access? Where will remote users access data from? 


+ 


Application needs: Which offices use the same applications? How many users are there per 
application? Are applications installed locally or centrally? 


+ 


Administrative strategies: Do you intend to manage eDirectory centrally or from many 
dispersed locations? 


¢ Naming standards for eDirectory objects: What naming standards are in force? Do any of 
them need to be changed or updated? 


+ 


Scalability and interoperability: How important are these on your network? Are you willing to 
compromise scalability and/or performance for other worthwhile goals? 


¢ Speed and efficiency: How important are these on your network? Are you willing to 
compromise speed and efficiency for other worthwhile goals? 
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¢ Fault tolerance: What steps have you taken to provide fault tolerance? Do additional options 
need to be implemented? 


Deciding Whether to Move Services 


If you decide to redesign your system, you need to determine whether to keep services in their 
original tree or move them to a new tree. As part of this process, you probably also want to remove 
any objects that are no longer being used. 


For File and Print, Design around Your WAN 


It is important that the WAN configuration is the first and foremost consideration for designing any 
eDirectory tree that caters primarily to file and print, particularly if your organization includes several 
remote facilities. In most cases, you should provide a partition for each remote location, even when it 
is a single-server site. 


For example, if you plan to have five OES servers in place that are primarily dedicated to providing 
eDirectory replica services, all of the Master replicas could be contained on one of these servers 
along with multiple replicas of the higher levels of the tree. Each remote server should include an R/W 
replica of its local partition. Make sure you have three writable replicas in place to provide adequate 
redundancy. 


Verify Your Redesign in a Lab First 


If you decide to re-engineer your tree, it’s a good idea to create the new tree in a lab to make sure you 
can work with its structure and that it’s actually going to work the way you want before you put it into 
production. 


Checking eDirectory Health 


Problems with eDirectory can derail a rollout very quickly. Make sure there are no significant health 
issues before you begin the upgrade. Determine whether the prerequisites have been met for 
introducing OES and eDirectory 8.8 into an existing tree or for transferring eDirectory from NetWare 
to OES. 

+ “What to Check For” on page 35 

+ “Health Check Tools To Use” on page 36 

+ “Check Requirements, Prerequisites, and Compatibility” on page 37 


+ “Check Application Compatibility” on page 37 


What to Check For 


NOTE: When you upgrade to eDirectory 8.8, a server health check is conducted by default to ensure 
that the server is safe for the upgrade. 
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Whichever option you choose, make sure each of the following is checked: 


+ 


eDirectory Version: Running different versions of NDS or eDirectory on the same version of 
NetWare can cause synchronization problems. All NDS versions should be at the latest version 
on their respective operating system platforms. If your version of NDS or eDirectory is outdated, 
download the latest software patch from Novell Directory Services Patches and Files (http:// 
support.novell.com/patches.html). 


Time Synchronization: NDS communication uses time stamps to uniquely identify objects and 
the object's modification time for synchronization purposes. Time stamps are assigned to each 
object and property to ensure the correct order for object and property updates. If servers in the 
tree are not synchronized to the correct local time (or more importantly, to each other) replica 
synchronization is not reliable and severe object corruption and data loss can be experienced. 
To avoid these problems, time needs to be in sync across all servers in the network. 


Server-to-Server Synchronization: NDS servers communicate changes made to objects and 
partition boundaries. This step verifies that no errors exist when NDS performs synchronization 
processes. 


Replica Ring Synchronization: This operation reads the Synchronization Status attribute from 
the replica object on each server that holds replicas of the partitions. It displays the time of the 
last successful synchronization to all servers as well as any errors that have occurred since. 


Synchronization Tolerances: This operation indicates the time periods since a server has 
synced with inbound and outbound data changes, how much data is outstanding, etc. 


Background Processes: These processes perform a variety of tasks, including replication of 
changes and maintenance of system information. 


External References: This check determines whether a replica containing the object can be 
located. 


Stuck Obituaries: These are object delete and move operations that have not completed 
successfully because mixed versions of DS have been used. Significant overhead is expended 
by the replica servers in retrying the obituary process constantly without success. Check the 
Flag States of the obituaries on all servers in the backlink lists for the obituaries. 


¢ Collision and Unknown Objects: In most cases, these objects can be deleted, but each 
should be investigated for origin and references first. 


+ Replica States: Check the partitions and states of the replicas stored in the server's NDS 
database files. 


+ eDirectory Schema Synchronization: Each NDS server has schema definitions that are 
used for creating and maintaining objects. Verify that schema synchronization between 
servers is working correctly. 


Health Check Tools To Use 


Depending on your preference, you can perform an eDirectory server health check in several ways: 


+ 


Use the health check utilities in eDirectory 8.8: NetIQ eDirectory 8.8 runs a health check by 
default with every upgrade before the actual package upgrade. 


+ OES health checks are run by default before an upgrade operation starts. 
+ NetWare health checks happen as part of the installation wizard. 


You can run the diagnostic tools (ndscheck on OES; dscheck on NetWare), to complete a health 
check at anytime. 


For additional information, including command parameters for each operating system, refer to 
“eDirectory Health Checks” in the Net/Q eDirectory 8.8 SP8 Installation Guide. 


OES 2015 SP1: Upgrading to OES—Best Practices Guide 


3.2.3 


3.3 


¢ Use iMonitor: You can use either of two methods (manual and automated) in iMonitor, a web- 
based diagnostic tool: 


+ Use the Navigator Frame (iMonitor > Navigator > Reports). 
+ Use the Assistant Frame (iMonitor > Assistant > Agent Health). 


Even with a large number of servers, this procedure tends to run very quickly (less than 5 
minutes for 15-20 servers if all of the servers are healthy). The process is the same for all 
operating systems. 


+ Use TID 10060600: You can view a tutorial or access a text version of the TID at http:// 
support.novell.com/additional/tutorials/index.html (http://support.novell.com/additional/tutorials/ 
index.html) 


Check Requirements, Prerequisites, and Compatibility 


For system requirements and prerequisites, see Installing or Upgrading NetIQ eDirectory on Linux in 
the NetiQ eDirectory 8.8 SP8 Installation Guide for a complete listing and explanation. 


Check Application Compatibility 


Check currently installed Novell and third-party applications to determine if eDirectory 8.8 is 
supported before upgrading your existing eDirectory environment. You can find the current status for 
Novell products in TID 31714342 “What Novell products are supported with NetIQ eDirectory 8.8” 
(http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=3171434&sliceld=1&docTypelD=DT_TID_1 1 
&dialogID=48117155&stateld=0%200%2048113961) 


If a product is not supported: 


¢ Do not install eDirectory 8.8 on the same server as the product. 


¢ Do not configure the product to search an eDirectory 8.8 server. 


As long as these conditions are met, you can still upgrade unaffected servers and services to OES 
and eDirectory 8.8 and run with a mixed tree until a replacement for the older application is found. 


For More Information 


For additional eDirectory design information, refer to “Designing Your NetIQ eDirectory Network” in 
the NetiQ eDirectory 8.8 SP8 Administration Guide. 


Upgrading eDirectory 


Use the information in the following sections to ensure a smooth eDirectory upgrade in connection 
with upgrading NetWare to OES. 


¢ Section 3.3.1, “Do Not Install or Upgrade to eDirectory 8.8 Separately from OES,” on page 38 
¢ Section 3.3.2, “Choosing an Upgrade Strategy,” on page 38 


¢ Section 3.3.3, “Moving, Creating, or Importing eDirectory Users,” on page 39 
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Do Not Install or Upgrade to eDirectory 8.8 Separately from 
OES 


Because OES services are tightly integrated with eDirectory, both the services and eDirectory must 
be upgraded at the same time. The OES install is not designed to handle a separate installation or 
upgrade of eDirectory 8.8. 


Choosing an Upgrade Strategy 


There are several basic strategies for setting up eDirectory on OES or upgrading to the OES platform: 


+ “Transferring eDirectory to a New Server” on page 38 
¢ “Starting Fresh with OES” on page 38 
+ “Adding a branch to an existing tree” on page 38 


+ “Manual Upgrade Using Replicas” on page 39 


Transferring eDirectory to a New Server 


If your current tree is meeting your needs, the simplest upgrade method is to transfer an existing 
NetWare server to a new OES server. 


Use the OES Migration Tool for this purpose, specifically the Identity Transfer functionality. For more 
information, see “Transfer ID Migration” in the OES 2015 SP1: Migration Tool Administration Guide. 


Starting Fresh with OES 


This is a good choice if you are unhappy with your existing tree (the tree hasn't kept up with 
organizational changes and growth). Moving to OES provides an opportunity to update the tree by 
starting from scratch. You might consider consolidating more services while adding new OES servers. 
Some Novell customers have incorporated specialty trees, such as an identity vault on SLES rather 
than on OES. 


In cases where eDirectory or the operating system and services are outdated, it sometimes makes 
sense to just redo the whole environment (new tree design, partitioning, replication strategies, newer 
utilities/services) rather than port the existing structure. 


The single biggest issue in many organizations is that NetWare and eDirectory haven't been patched, 
so Starting fresh is the easier option. This is true of file and print as well. Most customers who use this 
strategy are moving to OES from NetWare 5 and NDS 6 (which is limited to 1500 users). 


Adding a branch to an existing tree 


Some Novell customers transfer objects to a new OES branch and then gradually retire the older 
NetWare branch. By adding a branch, it's easier to drag and drop users and login scripts, certificates, 
and PKI so they don't need to be re-created. 
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Manual Upgrade Using Replicas 


If all you want to do is copy the existing eDirectory information from a NetWare server to anew OES 
server, without the OES server assuming the NetWare server's identity, you can move objects to a 
new OES branch and then gradually retire the older NetWare branch. When you've added a branch, 
it's easy to drag and drop users and login scripts, certificates, and PKI so they don't need to be re- 
created. 

1 Create a new OES server with a new eDirectory 8.8 tree. 


2 Create an eDirectory replica on the target OES server by attaching it to the same replica ring as 
the source NetWare server. 


This creates two instances of eDirectory in the environment. The OES Migration Tool does a 
non-destructive move of all services, and it needs both servers with their respective directories 
up and running. 


3 Allow the OES eDirectory installation to synchronize. 


If necessary, you can rework the layout of your tree structure, remap the location of all user 
objects in your new tree, and delete any user objects that are no longer needed. 


4 When eDirectory synchronization of the replica is complete, move the impacted services with the 
OES Migration Tool. 


5 Retire the older NetWare server. 


Except where dependencies exist, there is no required order for moving services in the same tree. An 
example of a dependency would be that the Archive and Versioning service depends on the file 
system. 


Moving, Creating, or Importing eDirectory Users 


If you have opted to create a new tree, you need to decide how to move user objects from one tree to 
another. Several options are available: 


+ “Using Novell Identity Manager” on page 39 
+ “Creating and Importing an LDIF file” on page 39 
+ “Using the OES Migration Tool” on page 40 


Using Novell Identity Manager 


One method is setting up a Novell Identity Manager connection between your old tree and your new 
one. This lets you easily synchronize user objects to the new tree. You can also use Identity Manager 
to remap the location of all user objects in your new tree. 


Creating and Importing an LDIF file 


Create an LDIF file containing user objects and use iManager to import it. Configure the LDIF file so it 
creates a Users' organization container and then places an object for each user in it. 


IMPORTANT: Replica and partition information cannot be imported by using an LDIF file. 


Upgrading eDirectory to OES 39 


40 


3.4 


Using the OES Migration Tool 


If you are creating a new tree, the Migration Tool can not only move the data but also create new 
users in the tree and match them to the data being moved. It can also match up users and trustees in 
the old tree with those in the new tree. 


It is probably easiest to create the new users by using one of the other methods and then match them 
up through the Migration Tool. 


Post-Upgrade Checks 


Check to be sure that your upgraded tree is healthy, that the services are running correctly, and that 
services are usable by all network users as expected. 


About Domain Services for Windows 


Novell Domain Services for Windows (DSfW) allows eDirectory users on Windows workstations to 
access storage on both OES servers and Windows servers by using native Windows and Active 
Directory authentication and file service protocols. 


DSfW enables companies with Active Directory and NetIQ eDirectory deployments to achieve better 
coexistence between the two platforms. 


¢ Users can work in a pure Windows desktop environment and still take advantage of some OES 
back-end services and technology, without the need for a Novell Client™ or even a matching 
local user account on the Windows workstation. 


+ Network administrators can use either Microsoft Management Console (MMC) or iManager to 
administer users and groups within the DSfW domain, including their access rights to Samba- 
enabled storage on OES servers. 


For planning and implementation information, see the OES 2015 SP1: Domain Services for Windows 
Administration Guide. 

¢ Section 3.5.1, “File Access,” on page 41 

¢ Section 3.5.2, “User Management,” on page 42 


¢ Section 3.5.3, “Storage Management,” on page 43 
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3.5.1 File Access 


Figure 3-1 DSfW File Access Overview 
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Table 3-1 DSfW File Access 


Access Methods Authentication 
eDirectory and Active Directory users on 
Windows workstations can access files 
through Windows Explorer (CIFS) or 
Internet Explorer (WebDAV Web 
Folders). No Novell Client is needed on 
the machine. 


For eDirectory users, file service 
access is controlled by 
authentication through the 
eDirectory server using common 
Windows authentication 
protocols, including Kerberos, 


. : NTLM, and SSL/TLS. 
Unlike Windows workgroup or Novell 


Samba, the user doesn’t need to have a 
matching username and password on 
the local workstation. 


For AD users, file service access 
is controlled by authentication 
through the AD server. 


Although not shown, Novell Client users 
can also access files through a normal 
NCP connection. 
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Windows server 


File Storage Services 


On OES servers, file storage 
services are provided by Samba 
to NSS or traditional Linux file 
systems. 


For eDirectory users, access to 
storage on Windows servers is 
available through a cross-forest 
trust. Access rights are granted 
by the AD administrator following 
the establishment of the cross- 
forest trust. 
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3.5.2 User Management 


Figure 3-2 DSfW User Management Overview 
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Table 3-2 DSfW User Management 


Management Tools 


iManager manages DSfW users like other 
eDirectory users. 


MMC manages both AD users and DSfW users 
as though they were AD users. 


| 


Authenticated Users 


y 


DSfW 
eDirectory server 


“ 


y 


AD server 


Users 


DSfW users must have the Default Domain Password policy 
assigned and a valid Universal Password. 


DSfW users are automatically enabled for Samba and LUM. 
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3.6 


Storage Management 
Figure 3-3 DSfW Storage Management Overview 
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Table 3-3 DSfW Storage Management 


Management Tools Storage 


Network administrators use native OES and Storage devices on OES servers can be either NSS or 
Windows storage management tools to create traditional Linux volumes. Samba management standards 
and manage storage devices on OES and apply to both volume types. 

Windows servers, respectively. 


Windows management tools can also manage 
share access rights and POSIX file system 
rights on DSfW storage devices after the 
shares are created. They cannot create the 
shares or perform other device management 
tasks. 


Additional eDirectory Resources 


Click the following links to access additional eDirectory resources. 


¢ eDirectory 8.8 Documentation (http://www.novell.com/documentation/edir88/) 


¢ eDirectory Health Check - Online Tutorial (http://support.novell.com/additional/tutorials/ 
tid10060600/) 


¢ eDirectory Training Courses (http://www.novell.com/training/courseware/catalog.jsp?pl=112) 
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4.1 


4.1.1 


4.1.2 


Upgrading NSS and Data Storage to OES 


¢ Section 4.1, “About NSS in OES,” on page 45 

¢ Section 4.2, “Platform Differences in NSS,” on page 46 

¢ Section 4.3, “Planning to Upgrade NSS,” on page 46 

¢ Section 4.4, “Moving NSS and Data,” on page 48 

¢ Section 4.5, “Post-Upgrade Procedures,” on page 49 

¢ Section 4.6, “Upgrading Distributed File Services (DFS) to OES,” on page 49 


About NSS in OES 


Novell Storage Services is available with NetWare 5.0 and later. The NSS kernel has been open 
sourced and is included in Novell SUSE SLES 9 SP1 Linux distribution and later and with Novell 
OES. The tools to manage NSS are available only in OES. 

¢ Section 4.1.1, “NSS Is Designed for the Enterprise,” on page 45 


¢ Section 4.1.2, “More Reasons to Consider NSS,” on page 45 


NSS Is Designed for the Enterprise 


The NSS file system is unique in many ways, mostly in its ability to simultaneously manage and 
support shared file services from different file access protocols. It is designed to manage access 
control in enterprise file sharing environments. 


One of its key features is the Novell Access Control Model, which securely scales to hundreds of 
thousands of users accessing the same storage. NSS and its predecessor (NWFS) are the only file 
systems that can restrict the visibility of the directory tree based on the user accessing the file 
system. Both NSS and NWFS have built-in ACL rights inheritance. 


NSS includes mature and robust features tailored for the file sharing environment of the largest 
enterprises. 


Dynamic Storage Technology works with NSS volumes on OES. 


More Reasons to Consider NSS 


Novell Storage Services is generally the best file system solution for customers transferring file 
sharing services from NetWare to OES. NSS file systems created on NetWare can be mounted on 
OES servers. 


The following characteristics of NSS on OES should be noted in your planning: 


+ NSS volumes are cross-compatible between OES and NetWare. NSS data volumes can be 
mounted on either NetWare or OES and the data can be moved between them. 


+ NSS devices and storage can be managed in the Web-based Novell iManager utility. NSS also 


supports third-party tools on both platforms for advanced data protection and management, virus 


scanning, and traditional archive and backup solutions. 
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4.2 


4.3 


4.3.1 


+ Ina mixed-platform cluster with Novell Cluster Services, NSS volumes can fail over between 
OES and NetWare, allowing for full data, trustee, and file system feature preservation when 
moving data to OES. However, best practice requires that you create all of the NSS volumes you 
need in the cluster on NetWare before you join any OES nodes to the cluster. After that point, 
you should not create additional NSS volumes or modify any of them until the cluster has only 
OES servers remaining. 


¢ In addition, NSS on OES: 
+ Retains all files, rights, metadata, restrictions, etc. 
+ Includes NetWare Trustee access control (richer than POSIX) 
+ Retains file system access (NCP) 
+ Retains all file system administration and management features 
+ Can be easily clustered with Novell Cluster Services (NCS) 


+ Is best for shared LAN file serving: excellent scalability in number of files; scales to millions 
of files in a single directory 


¢ Supports multiple data streams and rich metadata (its features are a superset of existing file 
systems on the market for data stream, metadata, namespace, and attribute support) 


¢ Is journaled 


Platform Differences in NSS 


Most NSS features that have been available on NetWare are now also available on OES. 


For the most up-to-date feature comparison, see “Comparison of NSS on NetWare and NSS on 
Linux” in the OES 2015 SP1: NSS File System Administration Guide for Linux. 


Planning to Upgrade NSS 


As you plan your NSS implementation, the following file system guidelines should be noted: 


¢ Section 4.3.1, “Identify NSS Coexistence and Migration Issues,” on page 46 


¢ Section 4.3.2, “Limitations,” on page 47 


Identify NSS Coexistence and Migration Issues 


For a complete discussion of the issues involved in the coexistence and migration of Novell Storage 
Services for OES that might affect your planning, see the following sections in the OES 2015 SP1: 
NSS File System Administration Guide for Linux: 


+ “Cross-Platform Issues for NSS” 


Discusses pool snapshots, NSS volumes and features, file access, and management tools 
¢ “Migrating NSS Devices to OES 2015 SP1” 


Includes guidelines for moving NSS pools and volumes between NetWare and OES servers and 
instructions for moving both clustered and non-clustered devices from previous versions of 
NetWare to OES. 
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4.3.2 


Limitations 


+ “Traditional NetWare File System Is Not Supported” on page 47 
¢ “Samba Access Requires LUM” on page 47 

+ “The Linux OS Can't Be Installed on NSS” on page 47 

+ “Moving Volumes Cross-Platform Has Limitations” on page 47 


+ “Pool Snapshots Cannot Be Moved” on page 48 


Traditional NetWare File System Is Not Supported 


The NetWare File System (NWEFS) was used in NetWare 3.x through 5.x as the default file system, 
and is supported in NetWare 6.x for compatibility. It is one of the fastest file systems available; 
however, it does not scale and is not journaled. An Open Source version of this file system is 
available for Linux to allow access to its file data. However, the open source version lacks the identity 
management tie-ins, and therefore, has little utility. 


NWES is not supported on OES and should, therefore, be moved—probably to the Novell Storage 
Services (NSS) file system. 


Samba Access Requires LUM 


For a broad explanation of Linux User Management (LUM), see “Linux User Management: Access to 
Linux for eDirectory Users” in the OES 2015 SP1: Planning and Implementation Guide. For 
information specific to NSS, see “Planning NSS Storage Solutions ” in the OES 2015 SP1: NSS File 
System Administration Guide for Linux. 


The Linux OS Can’t Be Installed on NSS 


You cannot install the Linux operating system on an NSS volume. OES requires a Linux traditional file 
system volume for the operating system, such as Ext3, Btrfs, or XFS. 


Moving Volumes Cross-Platform Has Limitations 


You can move an NSS volume that was created on NetWare cross-platform to an OES server. 
However, you should not move an NSS system (SYS:) volume from NetWare to OES unless you 
intend to use it as a data volume (or not at all) while it is mounted on the OES server. 


If you move an NSS system pool cross-platform, any volumes it contains function as data volumes on 
the OES server, including the SYS: volume. 


You can move storage devices containing NSS volumes between NetWare servers and OES servers. 
When you move an unshared device to a different server, you must decommission its volumes in 
eDirectory for the current server, then recommission them for the new server. For shared NSS pools 
and volumes, Novell Cluster Services provides this service automatically. 


NSS volumes that were originally created on NetWare can be moved cross-platform to an OES 
server. But only volumes that were originally created on NetWare can be moved back from OES to 
NetWare. 
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4.4 


4.4.1 


4.4.2 


4.4.3 


Pool Snapshots Cannot Be Moved 


NSS pools that are a source pool or a destination pool for NSS pool snapshots on NetWare cannot 
move cross-platform if you want to keep the pool snapshots. A pool snapshot is no longer available if 
you move its source pool or destination pool to an OES server. The snapshot no longer works even 
after you move the pools back to NetWare. 


Before you move an NSS pool cross-platform, make sure you delete any of its snapshots stored on 
other pools and any snapshots for other pools that it might contain. 


Moving NSS and Data 


¢ Section 4.4.1, “Moving NSS Devices Cross-Platform,” on page 48 
¢ Section 4.4.2, “Moving Data from NSS on NetWare to NSS on OES,” on page 48 
¢ Section 4.4.3, “Moving Data from NSS to Other Volume Types,” on page 48 


Moving NSS Devices Cross-Platform 


This is arguably the simplest method of all. NSS supports moving devices containing NSS volumes 
between any servers that support a compatible media format, including moves between NetWare 
servers and OES servers. For instructions, see “Moving Non-Clustered Devices From NetWare 6.5 
SP8 Servers to OES 2015 SP1” in the OES 2015 SP1: NSS File System Administration Guide for 
Linux. 


For issues with moving NSS volumes cross-platform between servers, see “Cross-Platform Issues for 
NSS.” 


Moving Data from NSS on NetWare to NSS on OES 


The OES Migration Tool supports transferring data from a source NSS volume on NetWare to a target 
NSS volume on OES. This method preserves both the Novell Trustee Rights for eDirectory users and 
the NSS directory and file attributes supported by only the NSS file system. 


For more instructions, see “Migrating File Systems to OES 2015 SP1” in the OES 2015 SP1: 
Migration Tool Administration Guide. 


Moving Data from NSS to Other Volume Types 


The OES Migration Tool also supports moving data from an NSS volume on NetWare to a Linux 
POSIX volume on OES. 


¢ If you configure the target Linux POSIX volume as an NCP volume and carefully follow the 
instructions, the Novell Trustee Rights are retained and only the NSS file and directory attributes 
are lost. 


+ If you move the data to a Linux POSIX volume target without configuring it as an NCP volume, 
the POSIX access model applies. eDirectory users must be enabled for Linux User Management 
to access data on Linux POSIX volumes. 
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4.5 


4.6 


If you are unsure about the implications briefly stated above, you should read the following sections in 


the OES documentation: 


¢ OES 2015 SP1: Planning and Implementation Guide 
+ “The Traditional Novell Access Control Model” 


+ “NSS Access Control on OES” 
+ “Novell Client (NCP File Services) Access” 


+ “eDirectory User Access to OES Servers” 


+ OES 2015 SP1: File Systems Management Guide 


+ “Understanding File System Access Control Using Trustees” 


+ “Coexistence and Migration Issues” 


Post-Upgrade Procedures 


After files are transferred, file permissions might need to be reset. As discussed earlier, Linux file 
system permissions are different from and not as granular as those used by NetWare. This becomes 
especially apparent for directories where multiple groups previously had access to the data within a 
file. On Linux file systems, this is not possible, so an alternative must be found. 


Novell recommends the following permissions as a starting point. You might need to change the 


permissions to better fit your needs. 


Table 4-1 File Permissions Recommended for File Types 


Type of files 


Home directories, such as /home/userid 


Permissions: 


user group other 


numeric value 


700 


User files, such as /home/userid/myfile 


640 


Shared team directory (where the group is used for access.) 


rwx rwx --- 


770 (execute on 
the directory allows 
accessing the 
directory; read 
allows seeing its 
contents) 


Shared team files (where the group is used for access.) 


rw- rw- --- 


660 


Upgrading Distributed File Services (DFS) to OES 


The DFS junction support on OES brings the NetWare Novell Distributed File System feature set to 


Linux with the following additions: 


+ VLDB services are cluster-enabled. 


¢ Junctions can point to subdirectories, not just the root of a volume. 


¢ All administration is performed via iManager. 


¢ Junctions can be created on any file system, not just Novell Storage Services. 
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Novell Distributed File Services (DFS) for the Novell Storage Services (NSS) file system provides 
location transparency of file data to end users. You can modify the underlying physical organization of 
data on NSS volumes to maximize the use and performance of available storage resources. With 
DFS, you can create a single virtual file system for data on NSS volumes that span multiple 
machines. 


DFS preserves the logical file organization from the user perspective by maintaining a Volume 
Location Database (VLDB) for all volumes in a DFS management context. Using junctions and the 
VLDB eliminates the user’s need to know the path to the physical location of the data. 


For information and instructions, see “Migrating DFS from NetWare to OES 2015 SP1.” in the OES 
2015 SP1: Novell Distributed File Services Administration Guide for Linux. 


For additional instructions for moving NSS devices cross-platform, see “Migrating NSS Devices to 
OES 2015 SP1” in the OES 2015 SP1: NSS File System Administration Guide for Linux. 
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5.1 


5.1.1 


Upgrading File Services to OES 


¢ Section 5.1, “Upgrading AFP File Services to OES,” on page 51 

¢ Section 5.2, “Upgrading CIFS File Services to OES,” on page 54 

¢ Section 5.3, “Upgrading Novell FTP to OES,” on page 59 

¢ Section 5.4, “Upgrading iFolder to OES,” on page 60 

¢ Section 5.5, “Upgrading NetWare Core Protocol (NCP) File Services,” on page 63 
¢ Section 5.6, “Upgrading NetStorage,” on page 66 


Upgrading AFP File Services to OES 


¢ Section 5.1.1, “About AFP File Services in OES,” on page 51 

¢ Section 5.1.2, “Platform Differences in AFP File Services,” on page 52 
¢ Section 5.1.3, “Planning to Transfer AFP Services,” on page 53 

¢ Section 5.1.4, “Upgrading AFP,” on page 54 

¢ Section 5.1.5, “Post-Upgrade Checks,” on page 54 


About AFP File Services in OES 


The AFP file services that were available on NetWare through the Native File Access Protocols 
(NFAP) service have been ported to OES as Novell AFP. 


The Novell AFP service lets users on Macintosh workstations access and store files on OES servers 


with NSS volumes using AFP (see Figure 5-1). 


Figure 5-1 How Novell AFP Works 
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The following table explains the information illustrated in Figure 5-1. 
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Access Points 


eDirectory users on Macintosh 


workstations have native access to the 


OES server. 


5.1.2 


Authentication 


All file service access is 
controlled by LDAP-based 
authentication through the 
eDirectory LDAP server. 


Although shown separately, 
eDirectory could be installed 
on the OES server. 


AFP File Services 


Of course, the same files can 
also be accessed through 
other OES file services (such 
as NetStorage) that connect to 
Linux volumes. 


Platform Differences in AFP File Services 


The differences in AFP services on NetWare and OES are summarized in the following table. 


Table 5-1 Platform Differences in AFP File Services 


Feature Description 


Administering 


AFP for NetWare 


Limited to starting and stopping the 
server. 


See “Enabling and Disabling AFP” 
in the NW 6.5 SP8: AFP, CIFS, and 
NFS (NFAP) Administration Guide 


AFP for OES 


Ability to configure AFP server 
parameters through iManager. 


See “Administering the AFP Server” 
in the OES 2015 SP1: Novell AFP 
for Linux Administration Guide. 


Filenames and Paths 


sys:\etc\ctxs.cfg 
sys:\etc\afpvol.cfg 


sys:\etc\afptcp.log 


/etc/opt/novell/afptcpd/ 
afpdircxt.conf 


/etc/opt/novell/afptcpd/ 
afpvols.conf 


/etc/opt/novell/afptcpd/ 
afptcpd.conf 


/var/log/afptcpd/afptcp.log 


Installation 


Customized installation during 
installation of NetWare 6.5. 


See, “Installing Novell Native File 
Access Protocols on a NetWare 6.5 
Server” in the NW 6.5 SP8: AFP, 
CIFS, and NFS (NFAP) 
Administration Guide 


Installation through YaST along with 
associated dependencies. 


See “Installing and Setting Up AFP” 
in the OES 2015 SP1: Novell AFP 
for Linux Administration Guide. 


Simple Password support 


Yes 


No 


Universal Password 


Yes. Limited to 8 characters. 


Yes. Over 8 characters. 


Upgrade/migration support 


Not Applicable 


Support to upgrade AFP from 
NetWare to OES. 


See “Migrating AFP to OES 2015 
SP1” in the OES 2015 SP1: Novell 
AFP for Linux Administration Guide. 


Mac versions supported 


Classic Mac, Mac OS 10.3, 10.4 
and 10.5 
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Mac OS 10.3 thru 10.7 


5.1.3 


Feature Description 


Cross-protocol locking 


AFP for NetWare 


Supported among AFP, CIFS, and 
NCP. 


AFP for OES 


Supported among AFP, CIFS, and 
NCP. 


Authentication methods Clear text Clear text 
Two-Way Random Key Exchange 
Random Exchange 
Diffie-Hellman Exchange 

Dynamic detection of volumes Yes Yes, but the AFP server needs to be 


reloaded. 


Choosing volumes to be exported Yes No. Exports all the volumes. 


Support for 64-bit architecture No Yes 


Planning to Transfer AFP Services 


The OES Migration Tool supports transferring AFP file services from NetWare to OES. The process is 
quite straightforward, but there are, of course, some planning steps that you must take to ensure a 
successful upgrade. 


+ “Requirements” on page 53 
¢ “Limitations” on page 53 


+ “Universal Password” on page 54 


Requirements 
Table 5-2 AFP Source and Target Server Requirements 


Source Server Target Server 


NetWare 5.1 or later OES 2015 or later 


The Novell AFP service pattern is installed but not 
configured. 


Data can be moved independently of the service. 
Users can always see what they have rights to see. 


Limitations 


The OES Migration Tool does not support transferring AFP services across eDirectory trees. 
However, AFP services can be effectively transferred by first moving the data to an OES target server 
in the other tree, and then configuring AFP on the target server. 


For details, see “Migrating Data to a Server in a Different Tree” in the OES 2015 SP1: Migration Tool 
Administration Guide and “Installing and Setting Up AFP” in the OES 2015 SP1: Novell AFP for Linux 
Administration Guide. 
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5.2 


Universal Password 


Although Simple Passwords were an option with AFP on NetWare, Novell AFP requires Universal 
Password, as listed in Section 5.1.2, “Platform Differences in AFP File Services,” on page 52. 


The process of upgrading AFP services to OES ensures that a Universal Password policy is assigned 
to all of the eDirectory contexts listed for AFP users on the NetWare server. If users currently have a 
Universal Password policy assigned, the tool checks for compliance with AFP requirements and 
modifies the policy if required. 


Upgrading AFP 


You can use either of the two migration types offered by the Migration Tool to transfer AFP file 
services from NetWare to OES: 


+ Migrate: If you are transferring just the AFP service and associated data to an OES server, you 
should perform a migration. For more information, see Section A.1.1, “Migrating Selected Data 
or Services,” on page 95. 


¢ Transfer ID: If you are transferring an entire NetWare server, including the AFP service and 
associated data, to an OES server, you should transfer the entire server configuration. For more 
information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 96. 


To transfer Novell AFP from NetWare to OES, follow the instructions in “Migrating AFP to OES 2015 
SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Post-Upgrade Checks 


+ “Verify Upgrade Success” on page 54 
+ “Preparing for the First Login” on page 54 


Verify Upgrade Success 


After the process is complete, be sure to complete the instructions in “Verifying the Migration 
Process” in the OES 2015 SP1: Migration Tool Administration Guide. 


Preparing for the First Login 


You must do two things to ensure that users can authenticate seamlessly to the transferred AFP 
service: 


1. Restart eDirectory with the environment variable NDSD_TRY_NDSLOGIN FIRST set to TRUE. 


2. Make sure that each user logs in for the first time by using either the Diffie-Hellman Exchange or 
clear-text authentication method. 


For more information, see “Cross-Platform Issues” in the OES 2015 SP1: Migration Tool 
Administration Guide. 


Upgrading CIFS File Services to OES 


¢ Section 5.2.1, “About CIFS File Services in OES,” on page 55 


¢ Section 5.2.2, “Platform Differences in CIFS File Services,” on page 56 
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¢ Section 5.2.3, “Planning to Upgrade CIFS Services,” on page 57 
¢ Section 5.2.4, “Upgrading CIFS,” on page 58 
¢ Section 5.2.5, “Post-Upgrade Checks,” on page 58 


About CIFS File Services in OES 


The CIFS file services that were previously available only on NetWare through the Native File Access 
Protocols (NFAP) service have been ported to OES as Novell CIFS. 


The Novell CIFS service lets users on Windows workstations access and store files on OES servers 
with NSS volumes without installing any additional software, such as the Novell Client (See Figure 5- 
2). 


Figure 5-2 How Novell CIFS Works 
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The following table explains the information illustrated in Figure 5-2. 
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5.2.2 


Access Methods 


eDirectory users on Windows 
workstations have two native Windows 
file access options: 


+ 


+ 


CIFS Client Access: Windows 
Explorer users can access and 


modify files on the OES server just 
as they would on any workgroup 


server share. 


Web Folder: Users can create Web 


Folders in Windows Explorer or 
Internet Explorer. 


Files on the OES server are 


accessed and maintained with the 


HTTP-WebDAV protocol. 


Authentication 


All file service access is 
controlled by LDAP-based 
authentication through the 
eDirectory LDAP server. 


Although it is shown 


separately, eDirectory could 


be installed on the OES 
server. 


CIFS File Services 


Of course, the same files can 
also be accessed through 
other OES file services (such 
as NetStorage) that connect to 
NSS volumes. 


Platform Differences in CIFS File Services 


The differences in CIFS services on NetWare and OES are summarized in the following table. 


Table 5-3 CIFS services on NetWare and OES 


Service NetWare OES 2015 SP1 
64-Bit Support No Yes 
CIFS-enabled shared NSS pool/ No No 
volume in a mixed NetWare-to-OES 

cluster 

CIFS-enabled shared NSS pool/ Yes Yes 
volume in a NetWare-to-NetWare or 

OES-to-OES cluster 

Cross Protocol Locking Yes Yes 
Distributed File Services for NSS Yes Yes 
Volumes 

Domain Emulation Yes Future 
Dynamic Storage Technology No Yes 
Support 

File and Record Locking Yes Yes 
iManager Support and Yes Yes 
Administration tool 

LDAP User (Subtree) Search No Yes 
Monitoring No Yes 
Multi-File System Support No Future 
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Service NetWare OES 2015 SP1 
Multi-processor/Multicore Server No Yes 

Support 

NSS Support Yes Yes 

NTLMv2 No Yes 

OpLocks Yes Yes 

Xen Virtualized Guest Server Yes Yes 
Environment 

Xen Virtualized Host Server NA No 


Environment 


Planning to Upgrade CIFS Services 


The OES Migration Tool supports transferring CIFS file services from NetWare to OES. The upgrade 
process is quite straightforward, but there are, of course, some planning steps that you must take to 


ensure SUCCESS. 


+ “Requirements” on page 57 


¢ “Limitations” on page 57 


+ “Universal Password” on page 58 


Requirements 


Table 5-4 CIFS Source and Target Server Requirements 


Source Server 


NetWare 5.1 or later 


Limitations 


Target Server 


OES or later 


The Novell CIFS service pattern is installed but not 
configured. 


Data can be moved independently of the service. 


Users can always see what they have rights to see. 


¢ “Cross-Tree Migration Not Supported” on page 58 


¢ “Server Configuration Information Not Transferred with Migration” on page 58 


+ “Upgrading Novell Samba Not Supported” on page 58 
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5.2.4 


5.2.5 


Cross-Tree Migration Not Supported 


The OES Migration Tool does not support transferring CIFS services across eDirectory trees. 
However, CIFS services can be effectively transferred by first moving the data to an OES target 
server in the other tree, and then configuring CIFS on the target server. 


For details, see “Migrating Data to a Server in a Different Tree” in the OES 2015 SP1: Migration Tool 
Administration Guide and “Installing and Setting Up AFP” in the OES 2015 SP1: Novell AFP for Linux 
Administration Guide. 


Server Configuration Information Not Transferred with Migration 


The CIFS shares configuration and CIFS Users contexts are transferred by using both migration 
types (Migrate and Transfer ID), but the server configuration information is transferred only with a 
Transfer ID migration. 


Upgrading Novell Samba Not Supported 


The OES Migration Tool does not support Novell Samba as a source service for transferal to Novell 
CIFS. 


Universal Password 


A Universal Password policy is required for Novell CIFS. 


Upgrading CIFS 


You can use either of the two migration types offered by the Migration Tool to transfer CIFS file 
services from NetWare to OES: 


¢ Migrate: If you want to move just the CIFS shares and associated data to an OES server, you 
can perform a migration. The CIFS server configuration is not transferred. For more information, 
see Section A.1.1, “Migrating Selected Data or Services,” on page 95. 


¢ Transfer ID: If you are transferring an entire NetWare server, including the CIFS service and 
associated data, to an OES server, then you should perform a Transfer ID migration. For more 
information, see Section A.1.2, “Transferring an Entire NetWare Server,” on page 96. 


To upgrade Novell CIFS from NetWare to OES, follow the instructions in “Migrating CIFS to OES 
2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Post-Upgrade Checks 
+ “Restarting CIFS” on page 58 
+ “Verifying Success” on page 59 
Restarting CIFS 


After the CIFS service is transferred, restart CIFS at a terminal prompt by using the following 
command: 


renovell-cifs restart 
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5.3 


5.3.1 


5.3.2 


5.3.3 


5.3.4 


Verifying Success 


Be sure to complete the instructions in “Verifying the Migration” in the OES 2015 SP1: Migration Tool 


Administration Guide. 


Upgrading Novell FTP to OES 


¢ Section 5.3.1, “About FTP File Services on OES,” on page 59 

¢ Section 5.3.2, “Platform Differences in FTP File Services,” on page 59 
¢ Section 5.3.3, “Planning,” on page 59 

¢ Section 5.3.4, “Transferring FTP Services to OES,” on page 59 

¢ Section 5.3.5, “Post-Upgrade Checks,” on page 60 


About FTP File Services on OES 


Novell FTP (File Transfer Protocol) is integrated with NetIQ eDirectory so that users can securely 
transfer files to and from OES or NetWare volumes. 


Platform Differences in FTP File Services 


There are no significant differences. 


Planning 


+ “Requirements” on page 59 


¢ “Limitations” on page 59 
Requirements 


Table 5-5 FTP Source and Target Server Requirements 


Source Server Target Server 


NetWare 5.1 or later OES with the Novell FTP service pattern installed but 


not configured. 


Limitations 


If a configuration exists on the target server, it is overwritten regardless of the migration type. 


Transferring FTP Services to OES 


You can use either of the two migration types offered by the Migration Tool to transfer FTP file 
services from NetWare to OES: 


¢ Migrate: Both migration on the same tree and migration to a different tree are supported. For 
more information, see Section A.1.1, “Migrating Selected Data or Services,” on page 95. 
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5.3.5 


5.4 


5.4.1 


¢ Transfer ID: If you are transferring an entire NetWare server, including the FTP service and 
associated data, to an OES server, then you should transfer the entire server configuration. 
Transfer ID migrations must occur within in the same tree. For more information, see 
Section A.1.2, “Transferring an Entire NetWare Server,” on page 96. 


To transfer Novell FTP from NetWare to OES, follow the instructions in “Migrating FTP to OES 2015 
SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Post-Upgrade Checks 


Verify a successful upgrade by making sure that the FTP service works as expected. For more 
information, see “Post-Migration Procedure” in the OES 2015 SP1: Migration Tool Administration 
Guide. For help with LUM-enabling FTP users, see TID 3503915 (http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=3503915&sliceld=1&docTypelD=DT_TID_1 1 
&dialog|ID=76627759&stateld=0%200%2076625913). 


Upgrading iFolder to OES 


¢ Section 5.4.1, “About iFolder on OES,” on page 60 

¢ Section 5.4.2, “Platform Differences in iFolder File Services,” on page 62 
¢ Section 5.4.3, “Planning,” on page 62 

¢ Section 5.4.4, “Upgrading iFolder,” on page 63 

¢ Section 5.4.5, “Post-Upgrade Checks,” on page 63 


About iFolder on OES 


NetWare runs only iFolder 2.x while OES runs iFolder 3.9, and as the version numbers imply, iFolder 
3.9 is much more robust and flexible. 
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Figure 5-3 How Novell iFolder 3.9 Works 
Access Methods Authentication/File Encryption iFolder 3 Services 


iFolder 3 
Sa Enterprise servers 


—_ P @ +a} 


iFolder Client 


for SLED i | 


Master server Slave servers 
Sync provides provide 


T access scalability 
iFolder Client (O-=) 


for Macintosh 


i LIES) iFolder 3 
Web Access Server 
iFolder Client 
for Windows : 
Upload or Download | j S 


p= 
=- W] Can run on an 

z iFolder 3 Enterprise server 

or a different OES server 


eDirectory LDAP 


iFolder 3 Web Access , server on the 
via a Web browser same or different 
OES server 
eDirectory 
LDAP server 


The following table explains the information illustrated in Figure 5-3. 


Access Methods Authentication/File Encryption Novell iFolder 3.9 
Services 

Linux, Macintosh, and Windows All file service access is Slave servers can be 

workstation users who have the Novell controlled by LDAP- based added as needed, 

iFolder Client installed can access and authentication through the providing the ability to 

modify their files in one or more eDirectory LDAP server. dynamically grow iFolder 

workstation folders. Changes are services without disrupting 


Although it is shown separately, users. 


automatically synchronized with the f f 
eDirectory could be installed on 


iFolder 3.9 Enterprise servers. 


the OES server. Local and network copies 
A Web interface lets users access their f of each file are 
files from any computer with an active Files can be encrypted for _ automatically 
network or Internet connection. transport using SSL connections synchronized by the Novell 
(HTTPS). iFolder Client and Server 
pieces. 


Additional overview information is available in “Overview of Novell iFolder” in the Novell iFolder 3.9.2 
Administration Guide. 
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5.4.2 Platform Differences in iFolder File Services 


There are numerous significant differences between iFolder 2.x and iFolder 3.9, including: 


+ Automatic Service Provisioning: Multiple servers participate in a single iFolder domain, and 
iFolder user assignments are automatically balanced across the domain. 


¢ Multiple iFolders: Users can use a virtually unlimited number of iFolders. 


¢ Sharing iFolders: Users can share their iFolders with other iFolder users, granting them full, 
read/write, or read only access. 


+ File-type Synchronization: If desired, you can limit which file types are synchronized. 


For a complete list of differences, see “Comparing Novell iFolder 2.x with 3.9” in the Novell iFolder 
3.9.2 Administration Guide. 


5.4.3 Planning 


+ “Requirements” on page 62 


¢ “Limitations” on page 62 
Requirements 


Table 5-6 iFolder Source and Target Server Requirements 


Source Server Target Server 


NetWare server with iFolder 2.x installed One or more OES servers installed. 


The iFolder 3.9 service pattern is installed on each 
server but not configured. 


All iFolder 3.9 servers, the iFolder 3.9 Web Access 
server, and eDirectory are up and running. 


Data must be moved before the iFolder service is 
transferred. 


If multiple servers are targeted, data migration is 
balanced by default. Users are then assigned to the 
appropriate iFolder. However, other provisioning 
options are available. 


For more information, see “Multi-Server Migration” in 
the OES 2015 SP1: Migration Tool Administration 
Guide. 


Limitations 


+ “Moving Encrypted iFolders” on page 63 
+ “iFolder 2.x User Policies Not Transferred” on page 63 
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5.4.4 


5.4.5 


5.5 


5.5.1 


Moving Encrypted iFolders 


The Migration Tool doesn’t move encrypted iFolders because user passphrases are needed. Each 

user with an encrypted iFolder needs to perform a client-side migration if they want their iFolder 2.x 
data moved to iFolder 3.9. For more information, see “Migrating from iFolder 2.x to iFolder 3.9.2” in 
the Novell iFolder 3.9.2 Cross-Platform User Guide. 


iFolder 2.x User Policies Not Transferred 


iFolder 2.x configuration settings, such as user policies, are not compatible with iFolder 3.9 and are 
therefore not transferred. You must set the policies for each user after the migration is complete. 


Upgrading iFolder 


You can use either of the two migration types offered by the Migration Tool to upgrade iFolder file 
services from NetWare to OES: 


¢ Migrate: Both migration on the same tree and migration to a different tree are supported. For 
more information, see Section A.1.1, “Migrating Selected Data or Services,” on page 95. 


¢ Transfer ID: If you are transferring an entire NetWare server, including the iFolder service and 
associated data to an OES server, then you should transfer the entire server configuration. 
Transfer ID migrations must occur within in the same tree. For more information, see 
Section A.1.2, “Transferring an Entire NetWare Server,” on page 96. 


To upgrade Novell iFolder on NetWare to OES, follow the instructions in “Migrating iFolder 2.x” in the 
OES 2015 SP1: Migration Tool Administration Guide. 


Post-Upgrade Checks 


As mentioned in “iFolder 2.x User Policies Not Transferred” on page 63, you must set a policy for 
each user after the upgrade is finished. 


Upgrading NetWare Core Protocol (NCP) File 
Services 


The NetWare Core Protocol (NCP) Server provides the same file services on OES that are available 
on NetWare. 


¢ Section 5.5.1, “About NCP File Services in OES,” on page 63 
¢ Section 5.5.2, “Planning to Upgrade NCP File Services,” on page 65 
¢ Section 5.5.3, “Only Data Transfers Are Required,” on page 66 


About NCP File Services in OES 


+ “What NCP Server Provides” on page 64 
+ “What NCP Server Alone Doesn't Provide” on page 65 
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What NCP Server Provides 


With NCP Server, you can define NCP volumes (NCP shares on Linux Ext3 and Reiser file systems). 
The advantage of using an NCP server is that you can control access using the Novell trustee model. 
Windows and Linux workstations running Novell Client software can access data and manage file 
sharing on OES servers just as they do on NetWare servers, unless they need NSS file attributes 
(see “What NCP Server Alone Doesn't Provide” on page 65). 


Novell NCP Server for OES enables support for login scripts, mapping drives to OES servers, and 
other services commonly associated with Novell Client access. This means that Windows users with 
the Novell Client installed can be seamlessly transitioned to file services on OES. 


Services provided by NCP include file access, file locking, security, resource allocation tracking, 
event notification, and synchronization with other servers. 


NCP is a client/server LAN protocol. Workstations create NCP requests and use TCP/IP to send them 
over the network. At the server, NCP requests are received, unpacked, and interpreted. 


Figure 5-4 illustrates the basics of NCP file services. 


Figure 5-4 NCP Services for OES and NetWare 
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The following table explains the information illustrated in Figure 5-4. 
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5.5.2 


Access Methods Authentication NCP Services 


Access is through an NCP All file service access is Files are stored on NetWare or 
client—specifically, the Novell controlled by eDirectory NCP volumes that the 
Client. authentication. administrator has created. 


The same core set of NetWare file 
attributes are available on both 
OES and NetWare. 


What NCP Server Alone Doesn’t Provide 


NSS file attributes and NCP services tend to get mixed together in the minds of NetWare 
administrators. It is important to remember that file and directory attributes are supported and 
enforced by the file system that underlies an NCP volume, not by the NCP server. 


For example, even though the Rename Inhibit attribute appears to be settable in the NCP client 
interface, if the underlying file system is Linux POSIX (Reiser, etc.) there is no support for the 
attribute, and it cannot be set. 


Salvage (undelete) and Purge are other features that are available only on NSS and only where the 
Salvage attribute has been set (the NSS default). They can be managed in the NCP client and 
through NetStorage, but they are not available on NCP volumes where the underlying file system is 
Linux POSIX. 


Some administrators assume they can provide NSS attribute support by copying or moving files, 
directories, and metadata from an NSS volume to a defined NCP volume on a Linux POSIX partition. 
However, this doesn’t work, because NSS file attributes are only supported on NSS volumes. 


Planning to Upgrade NCP File Services 


+ “Requirements” on page 65 
+ “Deciding Between a Linux POSIX File System and NSS” on page 66 
+ “The Novell Client Is Required” on page 66 


Requirements 
Table 5-7 NCP Source and Target Server Requirements 


Source Server Target Server 
NetWare 5.1 or later OES or later 
The NCP Server pattern is installed. 


Data can be moved independently of the server. Users 
can always see what they have rights to see. 
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Deciding Between a Linux POSIX File System and NSS 


For most system administrators, the most critical point of this decision is whether your organization 
relies on NSS file and directory attributes as a key component of the Novell Trustee Access model. If 
the answer is yes, then you should move your data to NSS volumes on OES, or mount existing NSS 
volumes on the OES servers. 


If your organization doesn't rely on NSS file and directory attributes and wants to transition to NCP 
volumes defined on Linux POSIX file systems, then you can create those volumes on the target 
servers and move the data by using the OES Migration Tool. 


The Novell Client Is Required 


Novell Client software is required to initiate an NCP connection between a Windows or Linux 
workstation running Novell Client software and an OES server running NCP Server services. 
Intelligence at both ends of the connection works together to verify that clients are who they claim to 
be, and that access controls are followed when using shared server files. 


5.5.3 Only Data Transfers Are Required 


You provide NCP services on an OES server by installing the NCP Server pattern. There is no 
upgrade path for the NCP server running on NetWare to NCP Server on OES. 


If the data is properly moved to ensure that trustee assignments are left intact, users can access their 
data using a Novell Client on a Linux or Windows workstation just as they did when the data resided 
on a NetWare server. 


5.6 Upgrading NetStorage 


¢ Section 5.6.1, “About NetStorage,” on page 66 
¢ Section 5.6.2, “Platform Differences in NetStorage File Services,” on page 68 
¢ Section 5.6.3, “NetStorage Is Not Transferred,” on page 69 


5.6.1 About NetStorage 


NetStorage provides secure Web access to files and folders on your OES and NetWare servers. It is 
a bridge between a company's protected Novell storage network and the Internet. Using a Web 
browser, your eDirectory users can securely copy, move, rename, delete, read, write, recover, and set 
trustee assignments for their files from any Internet-attached workstation, anywhere in the world, with 
nothing to download or install on the workstation. 


NetStorage on OES provides local and Web access to files on many systems without requiring the 
Novell Client (See Figure 5-5). 
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Figure 5-5 How NetStorage Works on OES 
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The following table explains the information illustrated in Figure 5-5. 
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5.6.2 


Access Methods 


Users have read and write 
access to files from 


+ Windows Explorer: Is 


enabled by the HTTP 


protocol with WebDAV 


extensions. 


+ Browsers: Users can 


access files directly by 


connecting to the 
NetStorage server. 


+ PDAs: PDA users with 


network connections 
can also access their 
files. 


Access is granted through 
login script drive mapping 
(NCP server required) or 

through Storage Location 
Objects. 


Authentication 


File service access is 
controlled by LDAP- 
based authentication 
through the eDirectory 
LDAP server. 


Although it is shown 
separately, eDirectory 
could be running on 
the OES server. 


NetStorage Server 


The NetStorage 
server receives and 
processes 
connection requests 
and provides access 
to storage on various 
servers on the 
network. 


Target Servers 


NetStorage on OES can 
connect eDirectory users 
to their files and folders 
stored in the following 
locations: 


+ The same targets as 
NetWare if the NCP 
server is running 


+ Windows workgroup 
shares (CIFS or 
Samba shares) 


+ Linux POSIX 
volumes through an 
SSH connection. 


Linux volumes can also 
be made available as 
NCP volumes. 


Management of NSS 
volumes on OES through 
NetStorage requires SSH 
access to the server. See 
“When Is SSH Access 
Required?” in the OES 
2015 SP1: Planning and 
Implementation Guide. 


Platform Differences in NetStorage File Services 


Although NetStorage provides the same basic services on NetWare and OES, there are significant 


configuration differences, most of which are a natural result of the platform differences between 


NetWare and OES: 


Table 5-8 NetStorage Platform Differences 


NetWare 


NetWare servers store data on NSS volumes. 


OES 2015 SP1 


OES servers accommodate many different file 


systems, including NSS. 


NetStorage is completely integrated with eDirectory 


an 


d NetWare. 


NetStorage is well integrated with eDirectory and OES. 


NetStorage relies heavily on NCP login scripts to 


provision user access to the storage locations it points 


to. 


NetStorage uses Storage Location Objects to provision 
storage locations that users access based on their 
rights. 


NetStorage provides automatic Web access for iFolder 


2.x when that service is installed on the same server 


as 


NetStorage. 


An integration with iFolder 3.9 is not needed because 
the iFolder 3.9 Web Server provides Web access for 
iFolder users. 
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Despite these differences, NetStorage on OES is every bit as valuable as NetStorage on NetWare 
and is well worth the small amount of time required to install and configure it. 


5.6.3 NetStorage Is Not Transferred 


Because of the differences explained above, it doesn’t make sense to transfer an exact NetStorage 
configuration from NetWare to OES. Instead, you should move your data by using the Migration Tool, 
then install and configure NetStorage on the OES2 server. 


For most networks, NetStorage needs to be installed on only one server; however, this might vary 
depending on the size of your network and your organization's needs. For example, if your company 
is geographically dispersed, you might want to install NetStorage on one server in each geographic 
region. 


NetStorage can also be set up in a clustered environment so that if a NetStorage server goes down, 
another NetStorage server in the cluster can take over the function of the downed server, and users 
don't lose access to data. 


For more information, see 


+ “NetStorage Implementation and Maintenance” in the OES 2015 SP1: Planning and 
Implementation Guide 


+ OES 2015 SP1: NetStorage Administration Guide for Linux. 
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6.1 


6.2 


6.3 


6.3.1 


Upgrading Print Services to OES 


¢ Section 6.1, “About iPrint,” on page 71 

¢ Section 6.2, “Platform Differences in iPrint,” on page 71 

¢ Section 6.3, “Planning to Upgrade iPrint to OES,” on page 71 
¢ Section 6.4, “Upgrading iPrint to OES,” on page 72 


¢ Section 6.5, “Additional Information,” on page 73 


TIP: If any printers in your environment have IPX enabled but not configured, you should disable 
them to free up JetDirect and LAN bandwidth. 


About iPrint 


The currently supported Novell print service, iPrint, is a greatly enhanced version of NDPS that is: 


+ Completely IP-based and platform independent on both the client and server side 
+ Not dependent on the Novell Client 
+ Web-based for both printer provisioning and deployment 


¢ Fully cluster-aware 


Platform Differences in iPrint 


There are two basic differences between iPrint on NetWare and iPrint on OES, neither of which 
should impact your upgrade plans: 


+ The back end infrastructures are different 
¢ iPrint on OES does not support NDPS/NCP client-based printing 


Both OES and NetWare support the same iPrint workstation agent. 


Planning to Upgrade iPrint to OES 


¢ Section 6.3.1, “Requirements and Recommendations,” on page 71 
¢ Section 6.3.2, “Limitations,” on page 72 


Requirements and Recommendations 


+ “Platforms” on page 72 
+ “Prepare the Workstations First” on page 72 
+ “Use DNS Names Rather than IP Addresses” on page 72 
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Platforms 


Table 6-1 iPrint Source and Target Server Requirements 


Source Server Target Server 
NetWare 5.1 or later OES with iPrint installed and the Driver Store 
configured 


Prepare the Workstations First 


Novell recommends deploying the iPrint agent to workstations before converting the backend 
infrastructure to OES. This will allow for the phased removal of the NDPS-based printers from the 
workstations and for a phased and transparent transition to OES printing services for users. 


Automated tools are available to deploy the iPrint agent to any workstations still using NDPS. This 
can also be done using a ZENworks application deployment. A silent install option is available. 


Use DNS Names Rather than IP Addresses 


An additional consideration is the use of literal IP addresses vs. DNS entries with the printer 
configurations deployed to the workstations. If the printer/manager configurations are using IP 
address assignments rather than DNS, Novell recommends deploying the iPrint agent to all of the 
workstations and changing the existing iPrint managers to a DNS configuration. This will allow you to 
convert to iPrint in OES without having to revisit the workstations. 


If you use DNS, the new iPrint infrastructure can be transferred to OES in phases while leaving the 
existing NetWare infrastructure in place. The users are converted over when the DNS entry for each 
individual print manager is changed. 


6.3.2 Limitations 


You can't migrate printer object ACL (Access Control List) assignments when migrating cross-tree. 


6.4 Upgrading iPrint to OES 


iPrint can be installed and configured on OES in parallel with an existing print environment to allow for 
a phased migration of users to the iPrint infrastructure. While iPrint can be used to support queue- 
based printing, it is not the preferred method (the only normal requirement to maintain a queue is to 
support legacy DOS-based applications that print directly to a queue rather than to a Windows printer 
or LPT port). 


Novell recommends the following steps to bring a current printing environment up to supported 
standards before transferring your print infrastructure to OES clusters as required: 

¢ Install and configure iPrint on any NetWare 6.5 clusters. 

¢ Install and configure all network printers in iPrint. 

¢ Install and configure web-based client deployment tools. 

¢ Set up iPrint on OES. 

¢ Deploy iPrint agents to workstations. 
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6.5 


The OES Migration Tool is available to copy a NetWare-based iPrint/NDPS environment to an OES 
iPrint infrastructure. This allows for a phased parallel installation approach to an OES upgrade with 
minimal user and administrative impacts. Using a mixed OES and NetWare based printing 
environment within the same tree is fully supported. 


Additional Information 


See “Migrating iPrint to OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 
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ret 


Upgrading Backup Services to OES 


¢ Section 7.1, “About Upgrading Storage Management Services (SMS),” on page 75 


About Upgrading Storage Management Services 
(SMS) 


The Novell Storage Management Services (SMS) backup infrastructure provides backup applications 
with the framework to develop a complete backup and restore solution. 


SMS helps back up file systems (Such as NSS) or application data, such as data from GroupWise on 
NetWare and SUSE Linux Enterprise Server (SLES), to removable tape media or other media for off- 
site storage. It provides a single consistent interface for all file systems and applications across 
NetWare and SLES. 


The upgrade path for SMS is to install it on the OES server. 
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8.1 


8.1.1 


8.1.2 


Upgrading Network Services to OES 


Network services are critical to event coordination and service discovery. 


¢ Section 8.1, “Upgrading DNS Services to OES,” on page 77 
¢ Section 8.2, “Upgrading DHCP Services to OES,” on page 78 
¢ Section 8.3, “Time Synchronization,” on page 79 

¢ Section 8.4, “Service Location Protocol (SLP),” on page 81 


Upgrading DNS Services to OES 


DNS on OES has been integrated with eDirectory. This means you can transition your existing DNS 
infrastructure from NetWare to OES, as well as centrally administer it the same way you do on 
NetWare. 

¢ Section 8.1.1, “About Novell DNS in OES,” on page 77 

¢ Section 8.1.2, “Platform Differences in Novell DNS,” on page 77 

¢ Section 8.1.3, “Planning to Upgrade Novell DNS,” on page 78 

¢ Section 8.1.4, “Upgrading DNS,” on page 78 


About Novell DNS in OES 


To accomplish eDirectory integration for DNS, Novell did a full port of NetWare DNS to OES to make 
it functionally equivalent to DNS in NetWare 6.5. Novell plans in the future to fully integrate all of the 
required functionality into the open source BIND project. 


Starting with OES, the iManager plug-in is no longer supported for management of DNS on OES. 
Java Console is the DNS administrative tool. If you are using the Novell NetWare DNS and DHCP 
services and hosting it via a cluster, this configuration can also be carried forward into an OES 
environment. 


Platform Differences in Novell DNS 


DNS platform differences are summarized in “DNS Differences Between NetWare and OES 2015 
SP1” in the OES 2015 SP1: Planning and Implementation Guide. 
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8.1.3 


78 


8.1.4 


8.2 


8.2.1 


Planning to Upgrade Novell DNS 


+ “Requirements” on page 78 


Requirements 
Table 8-1 DNS Source and Target Server Requirements 


Source Server Target Server 


NetWare 5.1 SP8 OES or later 
NetWare 6.0 SP5 or later 
NetWare 6.5 SP5 or later 
The Novell DNS service pattern is installed. 


The schema is extended, the DNS-DHCP group is 
created, and the RootServerlnfo and DNS-DHCP 
Locator objects are created. 


The installing administrator has rights to update files 
on the target server and is a member of the DNS- 
DHCP Group. 


Upgrading DNS 


DNS servers can be transferred both within and across eDirectory trees by using the Java Console. 
The OES Migration Tool doesn’t support DNS migrations. 


For instructions, see “Migrating DNS to OES 2015 SP1” in the OES 2015 SP1: Migration Tool 
Administration Guide. 


Upgrading DHCP Services to OES 


DHCP on OES has been integrated with eDirectory. This means you can transition your existing 
DHCP infrastructure from NetWare to OES, as well as centrally administer it the same way you do on 
NetWare. 

¢ Section 8.2.1, “About Novell DHCP in OES,” on page 78 

¢ Section 8.2.2, “Platform Differences in Novell DHCP,” on page 79 

¢ Section 8.2.3, “Planning to Upgrade Novell DHCP,” on page 79 

¢ Section 8.2.4, “Upgrading DHCP,” on page 79 


About Novell DHCP in OES 


The DHCP services in OES have been enhanced to store configuration information in eDirectory just 
as NetWare implementations do. 


After the DHCP information has been migrated to OES, administration can be performed through the 
DNS/DHCP Java Console. 
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8.2.2 


8.2.3 


8.2.4 


8.3 


8.3.1 


Platform Differences in Novell DHCP 


DHCP platform differences are summarized in “DHCP Differences Between NetWare and OES 2015 
SP1” in the OES 2015 SP1: Planning and Implementation Guide. 


Planning to Upgrade Novell DHCP 


Table 8-2 DHCP Source and Target Server Requirements 


Source Server Target Server 


NetWare 5.1 or later OES or later 


The Novell DHCP service pattern is installed and 
configured. 


The source and target servers have their times 
synchronized. 


Upgrading DHCP 


To transfer Novell DHCP services from NetWare to OES, follow the instructions in “Migrating DHCP to 
OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Time Synchronization 


Time synchronization is critical to maintaining the integrity of the tree. 


¢ Section 8.3.1, “About Time Synchronization in OES,” on page 79 
¢ Section 8.3.2, “Planning to Upgrade Time Synchronization Services,” on page 80 


¢ Section 8.3.3, “Transferring Time Synchronization Services,” on page 80 


About Time Synchronization in OES 


In earlier versions of eDirectory, replica synchronization required proper time synchronization. 
Currently, replica synchronization uses time stamps from host servers without checking for proper 
time synchronization. This means that if the host servers are not time-synchronized, events can be 
logged out of sequence, resulting in inconsistent information about what took place and in what order. 


What NTP Provides 


All servers with Internet access can get time from NTP servers on the Internet. NTP synchronizes 
clocks to the Universal Time Coordinated (UTC) standard, which is the international time standard. 
The hierarchy that indicates where each server is getting its time is referred to as a stratum, with the 
first time provider designated as stratum 1. 


A server that gets its time from a stratum 1 server is stratum 2, and so on. 


The TIMESYNC NLM can consume and provide NTP time, but it always functions as stratum 5. 
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8.3.2 


8.3.3 


Use a Reliable, External Time Source 


By default, NTP uses the server’s internal clock as its time provider, but it can be configured to use 
other time providers via the /etc/ntp.conf file. 


NTP time can be supplied from several sources: 


¢ Public Time Server. For small organizations (fewer than 100 servers), synchronizing servers to 
accurate public NTP servers provides sufficient time synchronization. To reduce traffic, it's best 
to have one or two servers synchronize with a public NTP source and have those servers 
provide time for the remaining servers. See http://ntp.isc.org/bin/view/Servers/WebHome. 


Reference Clock. Reference clocks are devices that synchronize via a variety of technologies 
including long wave radio signals, GPS transmissions, or CDMA technology. These can be 
expensive. 


Server's Local Clock. The server's internal clock can be used as a time source, but because 
time can wander, this is generally not a preferred solution. 


Network NTP Time Source. This is the recommended option for larger networks. In this case, 
you need to set up a server as an NTP time provider and then add the IP address of the time 
source to the /etc/ntp.conf file for servers that will use the designated server as the time 
provider. 


Planning to Upgrade Time Synchronization Services 


Both the OES and the NetWare installs automate the time synchronization process where possible. 
For complete information about planning and implementing a time synchronization strategy and 
setting up time providers and consumers, see “Time Services”, particularly “Implementing Time 
Synchronization” in the OES 2015 SP1: Planning and Implementation Guide. 


Also consider the following points. 


+ Designate the most reliable server in the subnet as the time provider. 
+ Configure at least two time providers to set fault tolerance. 


¢ Configure time consumers to contact a time provider within its own local network (so they don't 
contact time providers across costly WANs). 


+ Generally, only one server in a network should communicate with an external time provider. This 
reduces network traffic across geographical locations and minimizes traffic across routers and 
WANs. 


NOTE: The time synchronization modules in Novell Open Enterprise Server (OES) have been 
designed to ensure that OES servers can be introduced into an existing network environment without 
disrupting any of the products and services that are in place. 


Transferring Time Synchronization Services 


You can use either of the two migration types offered by the Migration Tool to transfer time 
synchronization services from NetWare to OES: 


¢ Migrate: Both migration on the same tree and migration to a different tree are supported. For 
more information, see Section A.1.1, “Migrating Selected Data or Services,” on page 95. 


¢ Transfer ID: Transfer ID migrations must occur within in the same tree. For more information, 
see Section A.1.2, “Transferring an Entire NetWare Server,” on page 96. 
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8.4 


8.4.1 


8.4.2 


To transfer time synchronization services from NetWare to OES, follow the instructions in “Migrating 
NTP to OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Service Location Protocol (SLP) 


SLP is not a migratable service, however, it is a critical component of OES and must be planned for in 
your upgrade strategy. 


¢ Section 8.4.1, “About SLP in OES,” on page 81 
¢ Section 8.4.2, “Platform Differences in SLP Services,” on page 81 
¢ Section 8.4.3, “Setting Up SLP on OES,” on page 82 


About SLP in OES 


SLP lets network services register their availability on the network. SLP agents then keep track of 
which services are available and provide that information to applications that need it. 


Platform Differences in SLP Services 


+ “SLP on NetWare” on page 81 
+ “SLP on OES” on page 81 


+ “Caveats” on page 81 


SLP on NetWare 


NetWare uses a Novell customized version of SLP called Novell SLP. 


On NetWare, SLP services are integrated with and configured to automatically work with eDirectory 
and other services. 


If you have a NetWare tree, you automatically have Novell SLP on your network and you can 
continue to use it as the SLP service during your upgrade to OES. 


SLP on OES 


Novell provides a basic level of SLP support when eDirectory is installed on an OES server. OES 
servers are configured with an SA that registers SLP-aware applications (Such as eDirectory) with the 
server. 


Caveats 


¢ If you are running NetWare 5.1 in your tree, it must be at SP8 to have SLP version 2 functionality. 
Older versions are not compatible with OpenSLP running on OES. 


¢ If your workstations can connect to the server using its IP address but not its DNS name, you 
need to update to Novell Client 4.91 SP5 or later. See TID 3890003 (hitp://www.novell.com/ 
support/php/ 
search.do?cmd=displayKC&doc Type=kc&externalld=3890003&sliceld=1&docTypelD=DT_TID_ 
1_1&dialoglID=66172729&stateld=0%200%2066174133). 
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8.4.3 Setting Up SLP on OES 


+ “Enabling Multicasting” on page 82 
¢ “Installing and Configuring OpenSLP” on page 82 
¢ “Additional Information” on page 82 


Enabling Multicasting 


SLP relies on multicasting by default; however, most Linux systems are not configured, by default, to 
provide multicast support. Enter the following at the shell prompt to determine whether multicasting is 
supported: 


route -n 
If multicasting is supported, you see an entry in the routing table for the 224.0.0.0 destination. 
If not: 


1 Open a terminal session. 
2 Change to the root user account. 


3 At the shell prompt, enter the following command: 
route add -net 224.0.0.0 netmask 240.0.0.0 dev interface 


(ethO is usually the interface parameter) 
4 Verify that the route has been added by entering route -n atthe shell prompt. 


Installing and Configuring OpenSLP 


OpenSLP is included with SLES 11 SP4 and installed as part of the eDirectory support infrastructure 
on OES servers. Installation instructions are included in “Specifying SLP Configuration Options” in 
the OES 2015 SP1: Installation Guide. 


For additional OpenSLP setup instructions, see “Setting Up OpenSLP on OES 2015 SP1 Networks” 
in the OES 2015 SP1: Planning and Implementation Guide. 


Additional Information 


+ NetlQ eDirectory 8.8 SP8 Administration Guide, “Configuring OpenSLP for eDirectory” 
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Upgrading Novell Cluster Services to 


OES 


Novell Cluster Services is a server clustering system that allows you to configure up to 32 OES 
servers into a high-availability cluster. You can move resources, either manually or automatically, to 
any server in the cluster. It is enabled for NetIQ eDirectory and supports failover, failback, and load 
balancing of individually managed cluster resources including data, applications, and services. 


¢ Section 9.1, “Overview,” on page 83 

¢ Section 9.2, “Planning to Upgrade Novell Cluster Services,” on page 84 
¢ Section 9.3, “Prerequisites,” on page 85 

¢ Section 9.4, “Caveats,” on page 86 

¢ Section 9.5, “Rolling Cluster Conversions,” on page 86 


Overview 


You can add OES nodes to an existing NetWare 6.5 cluster without bringing down the cluster, or you 
can create an all-OES cluster. With a mixed cluster, you can transfer services between OS kernels, 
and if services (Such as NSS) are alike on both platforms, you can set the services to fail over across 
platforms. 


Typical cluster configurations normally include a shared disk subsystem connected to all servers in 
the cluster. This disk subsystem can be connected via high-speed Fibre Channel cards, cables, and 
switches for best performance, or by a shared SCSI or iSCSI for a low-cost SAN. If a server fails, 
another designated server in the cluster automatically mounts the shared disk directories previously 
mounted on the failed server. This gives network users continuous access to the directories on the 
shared disk subsystem. 


Novell Cluster Services can be set up on OES in several ways: 
+ Implementing a new installation on OES that is separate from your NetWare cluster. The pattern 
install also installs these complementary services: 
+ Novell Backup/Storage Management Services (SMS) 
+ Novell Linux User Management (LUM) 
+ Novell Remote Manager (NRM) 
+ Adding OES nodes to an existing NetWare cluster 
¢ Changing existing NetWare cluster nodes to OES cluster nodes (Rolling Cluster Conversion) 


+ Using a mixed NetWare/OES cluster 


Using the Novell Cluster Services tool to manage live cluster transfers from the Novell NetWare OS to 
Novell SUSE Linux via a rolling conversion is one of the easier methods and is documented here. 
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9.2 


9.2.1 


9.2.2 


Planning to Upgrade Novell Cluster Services 


¢ Section 9.2.1, “Reviewing the Current Cluster,” on page 84 
¢ Section 9.2.2, “Upgrading Novell Cluster Services to OES,” on page 84 


¢ Section 9.2.3, “Additional Information,” on page 85 


Reviewing the Current Cluster 


Typically, the primary purpose of a cluster is to provide file and print services. Make sure you check 
the volume resources because it is easy to overload these services. As a general guideline, Novell 
recommends that NSS volume resources be kept at a total capacity of 80% or less. If you need to 
reduce the number of standalone servers in production, the logical approach is to move data and 
transfer services into the high availability resources of a cluster. 


+ Review the health of NCS background operations to resolve any operational issues with the 
cluster. 


+ Make sure all cluster nodes are up to the latest support pack levels. 
+ Avoid spanning LUNs across NSS pools 


+ Where necessary, review and modify the cluster design to take full advantage of the High 
Availability capabilities of current release software. 


Novell recommends the following steps to address both the reliability and the performance of your 
current cluster: 


e Make sure all NetWare nodes are at NetWare 6.5 SP7 or later 
+ Use relatively small LUNs and data volumes 

¢ Introduce OES nodes as required 

+ Reconfigure the SAN to host DST shadow volumes 


Upgrading Novell Cluster Services to OES 


There are a two paths for moving existing NetWare clusters to OES: converting the existing clusters 
(also referred to as a rolling cluster conversion) or using a parallel build. 


¢ Cluster Conversion (Same Cluster). In order to convert existing clusters, new OES servers 
need to be built with the same LUN visibility as the existing NetWare nodes and the new servers 
added to the existing cluster. The new OES nodes then mount the existing volumes and 
services, and the NetWare servers are removed from the cluster and removed from eDirectory. 
Although it is feasible to use a mixed NetWare and OES cluster temporarily as an upgrade 
strategy, Novell does not recommend it as a permanent production implementation. 


+ Parallel Build (New Cluster). A parallel-build OES upgrade strategy entails building a new 
separate OES cluster on the same SAN as the existing NetWare clusters. Doing so allows 
resources to be moved to the new cluster by changing LUN visibility from the old cluster nodes to 
the new. This can also be done in a phased approach. After the last resource is moved, the 
NetWare cluster can be removed from the tree. Because it is a new cluster, the virtual server 
names will change and login scripts and other references will need to be updated during the 
upgrade process. 


There are pros and cons to each approach so you need to do a more detailed analysis and have 
assistance from Novell Consulting before upgrading a cluster. 
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9.2.3 


9.3 


Novell Cluster Services software must be running on the OES server (SLES 11 and OES must be 
installed on every server you want to add to a cluster). You can install Novell Cluster Services and 
create a new cluster, or add a server to an existing cluster either during the SLES 11/OES installation 
or afterwards, using YaST. 


See “Installing Novell Cluster Services during an OES Installation” and “Installing Novell Cluster 
Services on an Existing OES Server” in the OES 2015 SP1: Novell Cluster Services for Linux 
Administration Guide. 


Additional Information 


Refer to the following sections in the OES 2015 SP1: Novell Cluster Services for Linux Administration 
Guide for additional information about transferring Novell Cluster Services to OES: 

+ “Converting NetWare Clusters to OES Clusters” 

¢ “Upgrading Clusters from OES 2 SP3 to OES 2015 SP1” 


Prerequisites 


+ Any NetWare cluster to be converted must be running at least NetWare 6.0. If you have a 
NetWare 5.1 cluster, you must upgrade to a NetWare 6.5 cluster before adding new OES cluster 
nodes or converting existing NetWare cluster nodes to OES cluster nodes. The process for 
converting 6.0 and 6.5 nodes is the same. 


+ Each OES server must contain at least one local disk device. 
+ Atleast 512 MB of memory must be available on each server in the cluster. 


While identical hardware for each cluster server is not required, having servers with the same or 
similar processors and memory can reduce differences in performance between cluster nodes. 


+ All nodes in a given cluster, whether NetWare or OES: 
+ Must be configured with a static IP address. 


An additional IP address needs to be available for the cluster and for each cluster resource 
and cluster-enabled pool. 


+ Must reside on the same IP subnet and in the same eDirectory tree. 


+ A shared disk subsystem should be connected to all servers in the cluster (optional, but 
recommended for most configurations) and should be properly set up and functional according 
to the manufacturer's instructions. 


+ We recommend configuring the disks contained in the shared disk system to use mirroring or 
RAID to add fault tolerance to the shared disk system. 


+ Atleast 20 MB of free disk space on the shared disk system needs to be available for creating a 
cluster partition. 


The Novell Cluster Services installation automatically allocates one cylinder on one drive of the 
shared disk system for the cluster partition. Depending on the location of the cylinder, the actual 
amount of space used by the cluster partition might be less than 20 MB. 


+ High-speed Fibre Channel cards, cables, and switch or SCSI cards and cables need to be 
installed to connect the servers to the shared disk subsystem. 


+ If you are using a fibre channel SAN, the host bus adapters (HBAs) for each cluster node 
should be identical. 


+ Ifyou are using iSCSI for shared disk system access, make sure you have configured iSCSI 
initiators and targets prior to installing Novell Cluster Services. 
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+ Novell Cluster Services software must be running on the OES server (SLES 11 and OES must 
be installed on every OES server added to a cluster). You can install Novell Cluster Services and 
create a new cluster, or add a server to an existing cluster either during the SLES 11/OES 
installation or afterwards, using YaST. 


See “Installing Novell Cluster Services during an OES Installation” and “Installing Novell Cluster 
Services on an Existing OES Server” in the OES 2015 SP1: Novell Cluster Services for Linux 
Administration Guide." 


9.4 Caveats 


There are several caveats that you need to be aware of: 


+ Resources created on OES cannot run on NetWare. 


+ You cannot add additional NetWare nodes to your cluster after adding a new OES node or 
changing an existing NetWare cluster node to an OES cluster node. If you want to add NetWare 
cluster nodes after converting part of your cluster to OES, you must first remove the OES nodes 
from the cluster. 


+ The server that holds the master eDirectory replica needs to be converted last, at the end of the 
rolling cluster conversion, not first. 


+ You can't change existing shared pools or volumes (storage reconfiguration) in a mixed 
NetWare/OES cluster. If you need to make changes to existing pools or volumes, you must 
temporarily bring down either all OES cluster nodes or all NetWare cluster nodes prior to making 
changes. Attempting to reconfigure shared pools or volumes in a mixed cluster can cause data 
loss. 


9.5 Rolling Cluster Conversions 


Performing a rolling cluster conversion from NetWare 6.5 to OES is one of the easier ways to upgrade 
Cluster Services to OES and keep your cluster up and running during the process. 


In this method, one server is converted to OES while the other servers in the cluster continue running 
NetWare 6.5. Then, as needed, other nodes can be converted to OES incrementally until all servers 
in the cluster have been converted. Although it is feasible to use a mixed NetWare and OES cluster 
temporarily as an upgrade strategy, Novell does not recommend it as a permanent production 
implementation. 


Refer to “Converting NetWare Clusters to OES Clusters” in the OES 2015 SP1: Novell Cluster 
Services NetWare to Linux Conversion Guide for instructions on performing a rolling cluster upgrade. 
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10.1 


10.1.1 


10.1.2 


Upgrading Other Novell Products to OES 


The information in this section was contributed by the GroupWise and ZENworks teams. 


¢ Section 10.1, “GroupWise,” on page 87 
¢ Section 10.2, “Identity Manager,” on page 90 
¢ Section 10.3, “ZENworks,” on page 91 


GroupWise 


¢ Section 10.1.1, “Source Platform Requirements,” on page 87 

¢ Section 10.1.2, “Target Platform Requirements,” on page 87 

¢ Section 10.1.3, “Preparing to Migrate,” on page 88 

¢ Section 10.1.4, “Caveats,” on page 88 

¢ Section 10.1.5, “Tool Options,” on page 88 

¢ Section 10.1.6, “Migration Instructions,” on page 89 

¢ Section 10.1.7, “Migrating GroupWise as Part of a Transfer ID Migration,” on page 89 
¢ Section 10.1.8, “Additional Information,” on page 90 


Source Platform Requirements 


You can migrate directly from any of the NetWare platforms that support GroupWise as listed in the 
GroupWise documentation (http://www.novell.com/documentation/groupwise2012/ 
gw2012_ guide_svrmig/data/ab32nt1.html). 


Target Platform Requirements 


Although other supported platforms are listed in the GroupWise documentation (http:// 
www.novell.com/documentation/groupwise2012/gw2012_guide_svrmig/data/ab32nt1.html), this 
guide focuses on migrating to OES. 


For specific planning instructions, see the following information: 


+ GroupWise 7: “Planning Your Basic GroupWise System” (http://Awww.novell.com/ 


documentation/gw7/gw7_install/data/a4bblzn.html) in the GroupWise 7 Installation Guide (http:// 


www.novell.com/documentation/gw7/gw7_install/data/a20gkue.html). 


¢ GroupWise 8: “Planning a Basic GroupWise System” (http://www.novell.com/documentation/ 
gw8/gw8_install/data/a4bblzn.html) in the GroupWise 8 Installation Guide (http:// 
www.novell.com/documentation/gw8/gw8_install/data/a20gkue.html). 


¢ GroupWise 2012: “Planning Your GroupWise Server Migration” (http://www.novell.com/ 
documentation/groupwise2012/gw2012_guide_svrmig/data/b65pbe1.html) in the GroupWise 
Server Migration Guide (http://www.novell.com/documentation/groupwise2012/ 
gw2012_guide_svrmig/data/ab32nt1.html). 
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10.1.3 


10.1.4 


10.1.5 


Preparing to Migrate 


Probably the most important tip to a successful migration is to make sure, before starting the 
migration, that the source NetWare server has the latest GroupWise support pack installed, and that 
GroupWise is running without problems. 


The GroupWise documentation includes thorough migration planning instructions in “Planning Your 
GroupWise Server Migration” (http://www.novell.com/documentation/groupwise2012/ 

gw2012 guide_svrmig/data/b65pbe1.html) in the GroupWise Server Migration Utility Installation and 
Migration Guide (http://www.novell.com/documentation/groupwise2012/gw2012 guide_svrmig/data/ 
ab32nt1.html). 


Caveats 


¢ Earlier Version of GroupWise: If you are running an earlier version of GroupWise on NetWare, 
you must upgrade to GroupWise 7 or GroupWise 8 with the latest support pack before migration 
to OES. 


¢ Migrating vs. installing GWIA and WebAccess: Novell Support recommends deleting the 
NetWare-based GWIA and WebAccess objects and then installing new GWIA and WebAccess 
services on OES, even though there are instructions for migrating the GWIA and WebAccess 
services from NetWare to OES in the documentation. 


Tool Options 


You have two options for migrating GroupWise from NetWare to OES: 


+ GroupWise Server Migration Utility: This lets you identify the components (Post Office agents, 
etc.) to be migrated from NetWare to OES and then installs GroupWise, configures the agents, 
and migrates the data—all in real time. The process is flexible, allowing you to choose which 
components to migrate when. 


During the initial transfer, the original server is maintained, letting you continue to run GroupWise 
on NetWare until the migration is complete and you are satisfied with the results. 


After the initial transfer, the utility guides you through testing the system on the new OES server, 
and then when you are ready to switch, it migrates any data that was altered since the initial 
transfer and activates GroupWise on the OES server. This is the only point in the process when 
post office agents are taken down. 


+ Manual Process: Although it is much more involved and labor-intensive, some prefer to migrate 
GroupWise manually. The results are the same as the automated process, if all of the 
instructions are followed carefully. 


Installation Is Included 


Some administrators have incorrectly assumed that they must install GroupWise on the target server 
prior to the migration. Actually, GroupWise is installed on the OES server as part of the migration. 


Upgrading the GroupWise Version Is Not Part of an OES Migration 


You cannot upgrade GroupWise as part of the migration to OES. 
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10.1.6 


10.1.7 


Migration Instructions 


+ “Manual Method” on page 89 
+ “Automated Method” on page 89 


Manual Method 


Table 10-1 Instructions for Manual GroupWise Migrations 


GroupWise Version 


See 


GroupWise 7 “Migration” (http://www.novell.com/documentation/ 
gw7/gw7_install/data/b2qqon2.html) in the GroupWise 
7 Installation Guide (http://www.novell.com/ 
documentation/gw7/gw7_install/data/a20gkue.html) 

GroupWise 8 “Manual Migration Steps” (http:/Avww.novell.com/ 


documentation/gwutilities/gw8_svrmig/data/ 
b2qqon2.html) in the GroupWise Server Migration 
Utility Installation and Migration Guide (http:// 
www.novell.com/documentation/gwutilities/ 
gw8_svrmig/data/ab32nt1.html) 


GroupWise 2012 


Automated Method 


“Manual Server Migration” (http:/Awww.novell.com/ 
documentation/groupwise2012/ 
gw2012_guide_svrmig/data/b2qqon2.html) in the 
GroupWise Server Migration Guide (http:// 
www.novell.com/documentation/groupwise2012/ 
gw2012_guide_svrmig/data/ab32nt1.html) 


Table 10-2 Instructions for an Automatic GroupWise Migration 


GroupWise Version 


GroupWise 7 and GroupWise 8 


See 


GroupWise Server Migration Guide (http:// 
www.novell.com/documentation/groupwise2012/ 
gw2012_guide_svrmig/data/ab32nt1.html) 


Migrating GroupWise as Part of a Transfer ID Migration 


Migrating GroupWise as part of a Transfer ID migration is essentially a three-phase process. 


+ “Migrating GroupWise” on page 90 


+ “Verifying that the GroupWise Migration Succeeded” on page 90 


+ “Transferring the NetWare Server’s Identity” on page 90 
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10.1.8 


10.2 


Migrating GroupWise 


If your NetWare server is currently running GroupWise, you must run the GroupWise Server 
Migration Utility before performing the Transfer ID migration. 


The GroupWise Server Migration Utility does the following: 


¢ It moves all GroupWise data and agents from a NetWare source server to an OES target server. 
¢ It sets up the GroupWise Agents to run on the IP address and DNS name of the target OES 
server. 


For instruction on running the GroupWise Server Migration Utility, see the GroupWise Server 
Migration Guide (http://www.novell.com/documentation/groupwise2012/gw2012 guide_svrmig/data/ 
ab32nt1.html). 


Verifying that the GroupWise Migration Succeeded 


You should verify that GroupWise has migrated correctly and is running successfully for several 
weeks in the OES environment before completing the Identity Swap. 


After the GroupWise migration, a copy of the GroupWise data is still located on the NetWare server. 
After you perform the Transfer ID migration, the GroupWise data is no longer accessible on the 
NetWare server. 


Transferring the NetWare Server’s Identity 


1 In ConsoleOne, change the IP address or DNS names for the POA, WebAccess, and GWIA to 
reflect the NetWare server IP address or DNS information. This is only required for the agents 
that were transferred using the GroupWise Server Migration Utility. 


2 Ensure that the changes have replicated through the system. 


3 If a domain was transferred during the GroupWise Server migration, change the IP address or 
DNS name for the MTA. 


4 Shut down the GroupWise agents running on the OES server. 
5 Perform the Identity Swap. 
6 After the Identity Swap has completed, bring up the GroupWise agents on the Linux server. 


Additional Information 


+ Product Documentation: 

+ GroupWise 7 (http://www.novell.com/documentation/gw7). 

+ GroupWise 8 (http://www.novell.com/documentation/gw8). 

+ GroupWise 2012 (http:/Awww.novell.com/documentation/groupwise2012). 
+ Novell GroupWise Web site (http://www.novell.com/products/groupwise/) 


Identity Manager 


For information about upgrading from NetWare to OES Linux, check the Cool Solutions Web site 
(http://www.novell.com/communities/coolsolutions). 
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10.3 ZENworks 


Many ZENworks features, such as policies and application distribution, are completely eDirectory and 
file system dependent. There is no dependency on the server OS. The remaining services that do 
have modules that run on a server, such as inventory and imaging, are dependent on a host OS. 


ZENworks 11 Configuration Manager is fully supported on OES 2 SP2 and later. If you are running an 
older version of ZENworks on NetWare, the following guides will help you upgrade to ZENworks 10 
running on OES. 


+ ZENworks 11 SP2 Configuration Management ZENworks Migration Guide (http:// 
www.novell.com/documentation/zenworks11/zen11_am_migration/data/bookinfo.html) 


IMPORTANT: If you are upgrading using an Transfer ID migration, be sure to complete the upgrade 
to Linux before migrating to ZENworks 11. 
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About Third-Party Applications 


Two of the most important categories of third-party applications are anti-virus software and backup 
software. 


Anti-Virus Software 


For a current list of antivirus software vendors that support Novell Open Enterprise Server, see Novell 
Open Enterprise Server Partner Support: Backup and Antivirus Support (http://www.novell.com/ 
products/openenterpriseserver/partners_communities.html). This list is updated quarterly. 


IMPORTANT: If you run server-based anti-virus software, configure it so that it does not scan 
GroupWise directory structures such as domains and post offices where file locking conflicts can 
create problems for the GroupWise agents. If you need virus scanning on GroupWise data, check the 
GroupWise Partner Products page (http://www.novell.com/partnerguide/section/468.html) for 
compatible products. 


Backup Software 


For a current list of backup software vendors that support Novell Open Enterprise Server, see Novell 
Open Enterprise Server Partner Support: Backup and Antivirus Support (http:/Awww.novell.com/ 
products/openenterpriseserver/partners_communities.html). This list is updated quarterly. 
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A.1 


A.1.1 


Tools for Upgrading to OES 


The following utilities are available to assist with migrations to OES or later. Each tool fulfills a specific 
migration or service-consolidation purpose as explained in the following sections: 

¢ Section A.1, “OES Migration Tool,” on page 95 

¢ Section A.2, “Server Consolidation and Migration Tool (SCMT),” on page 97 

¢ Section A.3, “NetWare Migration Wizard,” on page 97 

¢ Section A.4, “Additional Information,” on page 97 


OES Migration Tool 


The OES Migration Tool is the main tool for upgrading from NetWare to OES. The Migration Tool 
includes a migrated GUI interface that lets you drag and drop the volumes and services that you want 
to migrate. Terminal commands are also provided for those who prefer to work at a terminal prompt 
(command line). Both the GUI and command line methods are documented in the OFS 2015 SP1: 
Migration Tool Administration Guide. 


The OES Migration Tool runs exclusively on the destination OES server and pulls service 
configuration information and data from the NetWare source server. A Windows workstation is not 
required. 


The OES Migration Tool is installed on every OES server. 


When you run the GUI Migration Tool, after selecting the source and target servers, you are prompted 
to specify one of two migration types, as explained in the sections that follow. 

¢ Section A.1.1, “Migrating Selected Data or Services,” on page 95 

è Section A.1.2, “Transferring an Entire NetWare Server,” on page 96 


¢ Section A.1.3, “More About Using the Migration Tool,” on page 96 


Migrating Selected Data or Services 


The first option is the Migration type. 


Just as the name implies, a Migration is designed to migrate the services on multiple servers to a 
single, more powerful OES server. However, the type is very adjustable, letting you specify only a 
single volume or service to migrate at a time. Obviously this lets you move data and services with 
absolute flexibility. 


As with all migrations using the Migration Tool, the target server must be installed using the Pre- 
Migration Server installation pattern, and the patterns for the services you are planning to migrate to 
the server must be installed but not configured. 


For more information on this type of migration, see “Server Consolidations” in the OES 2015 SP1: 
Migration Tool Administration Guide. 
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A.1.2 Transferring an Entire NetWare Server 


The second option is the Transfer ID migration type. 


This powerful functionality lets you transfer an existing NetWare server’s identity, including its IP 
address, host name, eDirectory and security components, services, and data to an OES server. 


There are, of course, preparation steps to ensure that eDirectory and the NetWare server are healthy, 
and the services being migrated must be shut down during the migration process, but after the 
migration is finished, network users won't realize that anything has changed. 


Those customers who have used this tool have been very pleased with the results. 


For more information on this type of migration, see “Transfer ID Migration” in the OES 2015 SP1: 
Migration Tool Administration Guide. 


A.1.3 More About Using the Migration Tool 


¢ “Data Migration Support” on page 96 
¢ “Batch Data Migration Support” on page 96 
¢ “Service Migration Support” on page 96 


¢ “eDirectory Migration Support” on page 97 


Data Migration Support 


The primary purpose of the OES Migration Tool is to migrate data from the NetWare platform to the 
OES platform. Data migration tools can also be used to migrate data from OES 1 servers. A good 
place to start is “Migrating File Systems to OES 2015 SP1” in the OES 2015 SP1: Migration Tool 
Administration Guide. 


Batch Data Migration Support 


If you want to migrate data from multiple NetWare servers to a single OES server, you can create a 
cron job to automatically run multiple instances of the migfiles command sequentially. The 
Migration Tool GUI interface doesn’t currently support batch migrations. 


Service Migration Support 


Information about transferring individual services is in “Migration Scenarios” in the OES 2015 SP1: 
Migration Tool Administration Guide 


In most cases, you first need to install the service on the OES target server. Refer to the following 
sections in the Migration Tool Administration Guide: 

¢ “Migrating AFP to OES 2015 SP1” 

¢ “Migrating CIFS to OES 2015 SP1” 

¢ “Migrating DHCP to OES 2015 SP1” 

¢ “Migrating DNS to OES 2015 SP1” 

¢ “Migrating FTP to OES 2015 SP1” 

¢ “Migrating iFolder 2.x” 
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A.2 


A.3 


A.4 


¢ “Migrating iPrint to OES 2015 SP1” 
¢ “Migrating NTP to OES 2015 SP1” 


eDirectory Migration Support 


In OES, you migrate eDirectory using the new Identity Transfer functionality in the Migration Tool. See 
“Migrating eDirectory to OES 2015 SP1” in the OES 2015 SP1: Migration Tool Administration Guide. 


Server Consolidation and Migration Tool (SCMT) 


Support for migrating from newer NetWare platforms has not been removed from SCMT (as reflected 
in the Novell Server Consolidation and Migration Toolkit Administration Guide). However, Novell 
recommends using the OES Migration Tool rather than SCMT when possible. 


NetWare Migration Wizard 


The primary purpose of the Novell NetWare Migration Wizard is to migrate NetWare servers to new 
hardware or NetWare virtual machines. 


When the migration is complete, the new server replaces and assumes the identity of the old server 
on the network. 


IMPORTANT: For migrating to OES, use the new Identity Transfer feature found in the OES 
Migration Tool. For more information, see “Transfer ID Migration” in the OES 2015 SP1: Migration 
Tool Administration Guide. 


Additional Information 


+ Novell Upgrade or Migrate Web site. For information on the tools and resources currently 
available from Novell, visit the OES Upgrade or Migrate Web site (http:/Awww.novell.com/promo/ 
upgradeormigrate.html). 


¢ Links to Documentation. For a complete list of links to data and service migration instructions 
in the OES documentation, see the OES Documentation Web site (http://www.novell.com/ 
documentation/oes2015). 
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B.1 


B.1.1 


B.1.2 


B.1.3 


About the Management Tools in 
OES 


¢ Section B.1, “Novell iManager 2.7.x,” on page 99 

¢ Section B.2, “Novell Remote Manager (NRM),” on page 100 

¢ Section B.3, “OES User Rights Management (NURM),” on page 101 
¢ Section B.4, “About Other Management Tools,” on page 101 


Novell iManager 2.7.x 


Novell iManager is a Web-based administration console that provides secure, customized access to 
network administration utilities and content from virtually anywhere administrators have access to the 
Internet and a Web browser. 


For more information about iManager and its latest features, see What’s New in the NetIQ iManager 
2.7.7 Patch 4 Readme. 

¢ Section B.1.1, “Supported Web Browsers,” on page 99 

¢ Section B.1.2, “Caveats,” on page 99 

¢ Section B.1.3, “Upgrading to iManager 2.7,” on page 99 


Supported Web Browsers 


See “Using a Supported Web Browser” in the NetlQ® iManager Administration Guide. 


Caveats 


¢ In order for some iManager wizards and help to work, you must enable pop-up windows in your 
Web browser. 


+ iManager 2.7 can coexist in the same eDirectory tree with iManager 2.6. 


¢ If your network has more than three servers, or one or more servers that do not host eDirectory 
replicas, you must have SLP properly configured for iManager to log in. For more information, 
see “SLP” in the OES 2015 SP1: Planning and Implementation Guide. 


+ iManager 2.7 can manage any server running Novell eDirectory 8.6.2 or later. 


+ iManager 2.7 plug-ins are not compatible with previous versions of iManager. Additionally, any 
custom plug-ins you want to use with iManager 2.7 must be re-compiled in the iManager 2.7 
environment. 


Upgrading to iManager 2.7 


In light of the Caveats mentioned above, Micro Focus recommends that you simply install iManager 
2.7.X on your OES or later servers and download all of the plug-ins that apply to your services. For 
more information, see the Net/Q iManager Installation Guide. 
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B.2 Novell Remote Manager (NRM) 


Novell Remote Manager for OES is a browser-based utility that can be used to manage one or more 
OES servers from a remote location to monitor server health, change the server configuration, or 
perform diagnostic and debugging tasks. 


¢ It does not require a special client. 


¢ It provides a graphical interface that makes interpreting diagnostic information much more 
comprehensive and easier to manage. 


¢ It provides added functionality that is not available in other management utilities. 


¢ Section B.2.1, “Prerequisites,” on page 100 
¢ Section B.2.2, “About Novell Remote Manager and OES,” on page 100 


B.2.1 Prerequisites 


+ OES services must be installed when you install the OES server. 


¢ Supported browsers include Mozilla Firefox 1.0, Microsoft Internet Explorer 8, KDE 3.2 
Konqueror (limited functionality), or Safari 1.2 (limited functionality). 


+ The HTTPSTKD module must be loaded and running on the server. This module is selected, 
installed, and configured with a default configuration when you install any of the OES patterns 
(unless you deselect it). 


B.2.2 About Novell Remote Manager and OES 


There is no need to migrate Novell Remote Manager (NRM) from NetWare to OES. Instead, this 
service can be installed when any Open Enterprise Server pattern is installed. Then, if you have 
created server groups for monitoring NetWare 6.5 servers, they can be accessed and monitored from 
Remote Manager on OES just as they can from a NetWare server running NetWare 6.0 or later. 


However, NRM is configured somewhat differently on OES than on NetWare. When NRM is installed, 
it sets up a small Web server on the OES server. The interface and module is called HTTPSTKD. 
Basic configuration parameters are pre-set; however, these can be changed by editing the httpstkd 
config Of httpstkd PAM config files. See “Changing the HTTPSTKD Configuration” in the OES 
2015 SP1: Novell Remote Manager Administration Guide." 


You can log in as user Root, a local Linux user, or as an eDirectory user who is Linux User 
Management (LUM) enabled. 


+ If Linux User Management is enabled in your tree and is installed and configured on the local 
server, you can log in to Novell Remote Manager using your eDirectory credentials. See the 
OES 2015 SP1: Linux User Management Administration Guide for details. 


¢ If you log in as a local Linux user or as a non-Admin eDirectory user, you can see only the 
information that the user you log in as has rights to view. 
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B.3 


B.4 


OES User Rights Management (NURM) 


The OES User Rights Map (NURM) utility is used by administrators to map the Access Control List 
(ACL) of NSS resource that is owned by an identity in eDirectory to an identity in Active Directory. It 
maps the users and groups from eDirectory to Active Directory using a common name or any other 
field that is selectable by the tool. For more information, see NURM (OES User Rights Management) 
in the OES 2015 SP1: NSS AD Deployment and Administration Guide. 


About Other Management Tools 


For other OES utilities and tools, see OES 2015 SP1 Utility Changes in the OES 2015 SP1: Planning 
and Implementation Guide. 
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Workstation Considerations 


There are some impacts on network workstations resulting from a migration to OES. 


Domain Services for Windows 


Domain Services for Windows (DSfW) provides Windows users with seamless integration between 
eDirectory and Active Directory. For an overview of this new functionality, see Section 3.5, “About 
Domain Services for Windows,” on page 40. 


Novell Client 


As OES is implemented, existing clients can be used, such as Windows XP and Windows 7. Make 
sure your workstations are running the latest Novell Client for the platform. 


iFolder 


The iFolder client must be installed on all Macintosh, Linux, and Windows workstations that use this 
functionality in OES. 


iPrint 


The iPrint agent must also be installed on all Macintosh, Linux, and Windows workstations that use 
this functionality in the OES environment. 
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Server Consolidation 


The OES Migration Tool includes a Migrate migration type that is specifically designed to support 
server consolidation. For more information, see Section A.1.1, “Migrating Selected Data or Services,” 


on page 95. 
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E.1 


E.1.1 


E.1.2 


Examples 


This section contains a few real-world examples of upgrades to OES or later that Novell customers 
have done. If you have an example you want to share, please submit a User Comment for this page 
with your e-mail address, and we'll contact you. 


¢ Section E.1, “Replica and CA Server Migration,” on page 107 
¢ Section E.2, “Cluster Migration,” on page 109 
¢ Section E.3, “Server Identity Migration,” on page 116 


Replica and CA Server Migration 


The following is an example of transferring a NetWare 6.5 SP7 CA and eDirectory replica server to an 
OES server using the Transfer ID option in the OES Migration Tool. 


¢ Section E.1.1, “Overview,” on page 107 
¢ Section E.1.2, “FAQs,” on page 107 
¢ Section E.1.3, “Preparing and Transferring Your Replica Server,” on page 108 


¢ Section E.1.4, “Post-Migration Configuration,” on page 109 


Overview 


Table E-1 Service Migration Summary 


Pre-Migration Post-Migration 
A NetWare 6.5 SP8 server running as the master A single OES server running as the master replica 
replica server and certificate authority for the server and certificate authority for the eDirectory tree. 


eDirectory tree. 
The server has the same name and IP address as the 


NetWare server. 


This server currently provides these services: This server provides these services: 
+ SLPDA + SLPDA 
+ iManager + iManager 
* VLDB (DFS) * VLDB (DFS) 
+ NetStorage + NetStorage 
+ LDAP + LDAP 
* NTP 


FAQs 


+ Q: Do we need to remove the Certificate Authority and create a new one on the new server? 
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A: No. The Identity Transfer option migrates the existing eDirectory Certificate Authority to the 
new server. 


+ Q: To migrate the master, do we need to remove all eDirectory replicas, remove the server from 
eDirectory, build a new server with the same name, add replicas back, etc.? 


A: No. The Identity Transfer option migrates the existing eDirectory database to the new server. 


E.1.3 Preparing and Transferring Your Replica Server 


1 Prepare your servers by following the instructions in “Preparing for Transfer ID” in the OES 2015 
SP1: Migration Tool Administration Guide. 


Make sure you do the following: 


¢ Install the OES target server in the same context as the NetWare source server, using the 
Novell Pre-Migration Server pattern and the patterns for all services that correspond to the 
services running on the NetWare server. 


This ensures that eDirectory is installed on the target server without a replica and that the 
target server is prepared for all of the services being migrated. 


IMPORTANT: You must select the Pre-Migration Server install pattern during the initial 
OES installation. Otherwise, an eDirectory replica is installed and/or configured on the 
server, and the server is not a valid migration target server. 


Selecting the pattern later will not remove the replica configuration. 


If you install a server without selecting the pre-migration pattern initially, you must start fresh 
by performing a New Server installation and being sure to select Pre-Migration Server as 
one of the initial OES patterns. 


For instructions, see “Installing OES 2015 SP1 as a New Installation” in the OES 2015 SP1: 
Installation Guide. 


+ If you are moving data from NSS volumes on the NetWare source server, create 
corresponding NSS volumes on the OES target server. Be sure to use the same names as 
on the source server. 


Do not create any new volumes that will not have data migrated to them until after the 
Identity Transfer migration is completed. 


¢ Verify that the host name and DNS entries in your local /etc/hosts files and on the DNS 
server are correct. 


+ Apply the latest SLES 11 and OES patches from the Novell Customer Center to the target 
server. For more information, see “Updating (Patching) an OES 2015 SP1 Server” in the 
OES 2015 SP1: Installation Guide. 


+ If the source server is running NetWare 6.5 SP7, install the SMS patch (http:// 
support.novell.com/docs/Readmes/InfoDocument/patchbuilder/readme_5042400.html) first. 
If the source server is running SP8, this is not necessary. 


2 Migrate your server by following the instructions in “Using the Migration GUI Tool for Transfer ID” 
in the OES 2015 SP1: Migration Tool Administration Guide. 


Make sure you do the following: 


+ If you are moving data from NSS volumes on the NetWare source server, follow the 
instructions in “Migrating File Systems to OES 2015 SP1” in the OES 2015 SP1: Migration 
Tool Administration Guide. 
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+ Do not select iManager, VLDB, NetStorage or LDAP for migration. These services work 
automatically after the ID Transfer is complete. 


+ SLPDA must be manually reconfigured after the migration completes. 


E.1.4 Post-Migration Configuration 


1 


Set up the SLP DA on your OES server by following the instructions in “Setting Up an OpenSLP 
DA Server” in the OES 2015 SP1: Planning and Implementation Guide. 


Clean up the old eDirectory target server objects by following the instructions in “Cleanup 
Objects” in the OES 2015 SP1: Migration Tool Administration Guide. 


If you have DFS junctions, check one of them in this VLDB management context to make sure it 
is still working. If it is not working, rebuild the VLDB using the instructions in “Repairing the 
VLDB” in the OES 2015 SP1: Novell Distributed File Services Administration Guide for Linux. 


For information about time synchronization services on a Novell network, see “Time Services” in 
the OES 2015 SP1: Planning and Implementation Guide. 


Verify that all of the other services are working as expected. 


E.2 Cluster Migration 


E.2.1 


The following is an example of doing a rolling cluster upgrade from an NetWare 6.5 SP7 cluster to an 
OES cluster. 


+ 


+ 


+ 


+ 


+ 


Section E.2.1, “Overview,” on page 109 

Section E.2.2, “General Notes and Tips,” on page 110 

Section E.2.3, “Preparing to Migrate the Cluster,” on page 110 
Section E.2.4, “Transferring DHCP in the Cluster,” on page 111 
Section E.2.5, “Transferring DNS in a Cluster,” on page 112 
Section E.2.6, “iPrint Migration in a Cluster,” on page 113 
Section E.2.7, “Transferring AFP in a Cluster,” on page 115 
Section E.2.8, “Transferring CIFS in a Cluster,” on page 116 


Overview 


Table E-2 summarizes the pre-migration and post-migration status of the cluster being migrated. 


Table E-2 Service Migration Summary 


Pre-Migration: Three-node NetWare 6.5 SP7 Post-Migration: Three-node OES Cluster 
Cluster 
Each node contains some eDirectory replicas Each node contains some eDirectory replicas 
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Pre-Migration: Three-node NetWare 6.5 SP7 Post-Migration: Three-node OES Cluster 


Cluster 
Each node has access to fiber-attached shared Each node has access to fiber-attached shared 
storage that includes: storage that includes: 

+ Several clustered NSS volumes for home + Several clustered NSS volumes for home 

directories and shared file systems directories and shared file systems 

+ One clustered NSS volume for NDPS and iPrint + One clustered NSS volume for iPrint 

+ Clustered DHCP + Clustered DHCP 

+ Clustered DNS + Clustered DNS 

+ Clustered AFP (NFAP) + Clustered Novell AFP 

+ Clustered CIFS (NFAP) + Clustered Novell CIFS 


E.2.2 General Notes and Tips 


¢ Inthe YaST install, clustering is disabled by default. To set up clustering, you must enable it for 
configuration. See “Novell Cluster Services Parameters and Values” in the OES 2015 SP1: 
Installation Guide. 


¢ Clustering on OES is case-sensitive. Always make sure that you have specified the correct case 
for each name, etc. The SPD on the OES node is created exactly as you specify it. (NetWare 
was case-insensitive.) 


+ NetWare cluster names display in uppercase. Using lowercase for OES cluster names makes 
them easier to distinguish from the NetWare names. 


+ On NetWare nodes, the load and unload scripts are stored in eDirectory and accessible through 
iManager. 


+ On OES nodes, the load and unload scripts are dynamically created in /var/run/ncs from the 
scripts stored in eDirectory each time that you cluster-migrate a cluster resource to the OES 
node. 


Scripts are retained only while the OES server is running. If the server goes down for any 
reason, the scripts are removed. This is not a problem, however, because they are created again 
when you cluster-migrate the cluster resources. 


+ NetWare has a limitation of 1024 characters in scripts. Linux doesn't have this limitation. 


The best solution for this limitation is to create a small script to call the larger scripts. The script 
must be the same on each box. Section E.2.4, “Transferring DHCP in the Cluster,” on page 111 
illustrates this concept. 


¢ There's a utility called sbdutil that lets you manage the sbd on OES. For documentation, 
access the sbdutil man page on a clustered server. 


E.2.3 Preparing to Migrate the Cluster 
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1 Read through Table E-3 to understand what happens to the existing volumes during a cluster 
migration. 
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Table E-3 What Happens to Existing Volumes During a Cluster Migration 


Pre-Migration Status Migration Action Post-Migration Status 


Users volume active on NetWare  Cluster-migrates to an OES node Users volume active on OES 


Shared volume active on Cluster-migrates to an OES node Shared volume active on OES 
NetWare 
NDPS volume active on NetWare Migration Tool migrates Offline 

configuration, etc. to the new 

iPrint volume. 


DNS volume active on NetWare Moved by iManager to the new Offline 
DNS2 volume on OES. 


2 Create all of the NSS volumes that are required for your service migrations as listed in Table E-3. 


WARNING: This must be done while the cluster has only NetWare nodes. If you have already 
joined OES nodes to your cluster, make sure that you remove them from the cluster before you 
create the NSS volumes. 


Table E-4 New NSS Pools and Volumes Are Required 


Create These Migration Action Post-Migration Status 


Destination iPrint pool and Cluster-migrates to an OES node iPrint volume active on OES 
volume (newly created through 
the NetWare server) 


Destination DHCP pool and Cluster-migrates to an OES node DHCP volume active on OES 
volume (newly created through 
the NetWare server) 


Destination DNS2 pool and Cluster-migrates to an OES node DNS2 volume active on OES 
volume (newly through the 
NetWare server). 


E.2.4 Transferring DHCP in the Cluster 


1 Before starting the migration, create the Destination DHCP volume specified in Table E-4. 


2 Add one or more OES servers to the cluster. For more information, see “Adding New OES 
Nodes to Your NetWare Cluster” in the OES 2015 SP1: Novell Cluster Services for Linux 
Administration Guide. 


3 Set up an OES DHCP cluster resource using the instructions in the first three section only of 
“Installation and Configuration” in the OES 2015 SP1: DNS/DHCP Services for Linux 
Administration Guide. 


4 Edit the destination DHCP pool resource load script and insert the following line just before the 
last (exit 0) line: 


/destination_dhcp_volume/dhcp_cluster.sh 


where destination_dhcp_volume is the path to the destination DHCP volume listed in Table E-3. 
For example, insert the following line: 
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E.2.5 


112 


10 


11 
12 
13 


+ 


+ 


/media/nss/DHCP_VOLUME/dhcp_cluster.sh 


IMPORTANT: This step is required to circumvent the 1024 byte script-size limitation on NetWare 
mentioned in Section E.2.2, “General Notes and Tips,” on page 110. 


Download the dhcp_cluster.sh (http://www.novell.com/documentation/oes11/scripts/ 
dhcp_cluster.sh) script file from the OES Documentation Web site. 


Using a UNIX-compatible text editor, replace <DHCP_VOLUME> in the dhcp_cluster.sh script 
with the local mount point of your destination DHCP volume. 


For example, MOUNT_POINT="/media/nss/DHCP_ VOLUME". 


Using the instructions in “Migrating DHCP to OES 2015 SP1” in the OES 2015 SP1: Migration 
Tool Administration Guide, migrate the NetWare DHCP configuration to one of the OES servers 
added to the cluster in Step 2. 


Copy the /etc/dhcpd. conf file to the destination DHCP volume. 
For example cp /etc/dhcpd.conf /media/nss/DHCP_VOLUME/dhcpd.conf. 
Edit the dhcpd.conf file you copied in Step 8, as follows: 


9a Change the ldap-server IP address to the IP address associated with your destination 
DHCP pool. 


9b Change the ldap-dhcp-server-cn to the OES DHCP Server Object created by the 
Migration Tool in Step 7. 


Copy the migrated_server.leases file from the /var/opt /novell/dhcp/leases folder to the 
/var/1ib/dhcp/db folder on your Destination DHCP Volume and rename it to dhcpd. leases. 


Continuing with the same example, you use the following command to copy and rename the file: 


cp /var/opt/novell/dhcp/leases/DHCP SERVER.leases /media/nss/DHCP_VOLUME/var/ 
lib/dhcp/db/dhcpd. leases. 


Offline the DHCP cluster resource that has been running on NetWare. 
Online the OES DHCP cluster resource. 


(Optional) Use iManager to enable the DHCP server as the authoritative server. 


Transferring DNS in a Cluster 


“Using Java Console to Migrate DNS Servers within the Same eDirectory Tree” on page 112 


“Installing and Configuring a Cluster-Enabled DNS” on page 112 


Using Java Console to Migrate DNS Servers within the Same 
eDirectory Tree 


See “Migrating DNS from NetWare to OES 2 SP3 Linux” in the OES 2 SP3: Migration Tool 
Administration Guide. 


Installing and Configuring a Cluster-Enabled DNS 


1 


2 
3 


Verify that all OES cluster nodes have the DNS pattern installed with a common locator group 
context. 


Mount the shared volume on one of the OES nodes in the cluster. 


Execute the following script at the command prompt: 
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/opt/novell/named/bin/ncs dir.sh mount_point username 


where mount_point is the Destination DNS2 volume listed in Table E-4 and username is the fully 
distinguished name of the DNS user (named by default). 


For example, you might enter the following command: 

/opt/novell/named/bin/ncs_ dir /media/nss/DNSVOL/ cn=named.o=novell.T=MyTree 

The script creates the following directory: 

/media/nss/DEST_ DNS2_VOL/etc/opt/novell/named 

The script also assigns access and ownership rights for the preceding directory to the DNS user. 
4 Run the DNS Server by using the following command: 

/opt /novell/named/bin/novell-named -u DNS_User -V DEST _DNS2_VOL 

This step ensures that DNS server is running on the cluster node. 


5 Click Cluster > Cluster Options, then select the Destination DNS2 cluster pool resource and 
click Details. 


6 Click the Scripts tab. 
6a Click Load Script. 
6b Add following line before exit o to load DNS. 


exit_on_error /opt/novell/named/bin/novell-named -u DNS User -V 
DESTINATION DNS2_VOLUME 


6c Click Unload Script. 
6d Add following line at the beginning to unload DNS. 


killproc -p /var/opt/novell/run/named/named.pid -TERM /opt/novell/named/ 
bin/novell-named 


7 Set the Destination DNS2 cluster resource offline and then online by using the Clusters > 
Cluster Manager task in iManager. 


8 Verify that DNS services are functioning correctly. 


E.2.6 iPrint Migration in a Cluster 


+ “How Clustered iPrint Migration Works” on page 113 
+ “Tips and Caveats” on page 114 


¢ “Transferring iPrint in a Cluster’ on page 114 


How Clustered iPrint Migration Works 


The OES Migration Tool (miggui) contains an NLM named PSMINFO.NLM that copies all of the iPrint 
data from the cluster to an XML text file named psminfo.xml1 on the iPrint NSS volume that you 
created in Step 2 on page 111. The psminfo.xml1 file is located in an /ndps directory at the root of 
the volume. 


The migration tool uses the information in psminfo.xm1 to create new printer objects, set up the 
driver store, create printer agents, etc. The tool also changes the names of the old iPrint objects in 
eDirectory by appending _nw to each name. The old names can then be applied to the new printer 
objects. All changes are completely transparent to iPrint users. 
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Tips and Caveats 


+ Legacy queue-based printing cannot be serviced by an OES Printer Agent. 


+ You can manage both OES iPrint and NetWare iPrint from NetWare, but you can only manage 
OES iPrint from OES. 


+ You must create the iPrint NSS pool and volume as instructed in Step 2 on page 111 prior to 
adding OES nodes to the cluster or running the migration. 


Transferring iPrint in a Cluster 


1 Download the iprint_load.sh script (http://www.novell.com/documentation/oes11/scripts/ 
iprint_load.sh) and the iprint_unload.sh script (http:/Awww.novell.com/documentation/oes11/ 
scripts/iprint_unload.sh) from the OES Documentation Web site. 


2 Customize the iPrint load script for your iPrint pool resource by doing the following: 
2a In iManager, access the load script for the destination iPrint pool resource. 


2b Copy and paste the contents of the downloaded iprint_1load.sh file below the last line of 
the current load script. 


2c Using the information in the current script, replace each variable (indicated by <angle 
brackets>) with the correct values for the cluster resource. 


For example, if the first line in the current script reads 
nss /poolactivate=POOLNAME 
Modify the third line in the downloaded script to read 
exit_on_error nss /poolact=POOLNAME 
2d Remove all of the lines down to the first line you inserted. 
2e Click Apply. 
3 Customize the iPrint unload script for your iPrint pool resource by doing in the following: 
3a In iManager, access the unload script for the destination iPrint pool resource. 


3b Copy and paste the contents of the downloaded iprint_unload.sh file below the last line 
of the current unload script. 


3c Using the information in the current script, replace each variable (indicated by <angle 
brackets>) with the correct values for the cluster resource. 


For example, if the first line in the current script reads 


ncpcon unbind 
--ncpservername=CLUSTERNAME POOLNAME SERVER --ipaddress=192.168.10.10 


Modify the third line in the downloaded script to read 


ignore error ncpcon unbind 
--ncpservername=CLUSTERNAME POOLNAME SERVER --ipaddress=192.168.10.10 


3d Remove all of the lines down to the first line you inserted. 
3e Click Apply > OK. 
4 In iManager > Cluster Options, select the iPrint cluster resource object and click the Details link. 


5 On the Cluster Pool Properties page, click the Preferred Nodes tab and move all of the NetWare 
nodes to the Unassigned column. 


6 Offline and then online the cluster resource. 


7 On the server where the iPrint cluster resource is running, open a terminal and enter the 
following commands: 
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ed /opt/novell/iprint/bin 
./iprint_nss_ relocate -a admin.fqdn -p password -n NSS/path -1 cluster 
For example, enter 


./iprint_nss_ relocate -a cn=admin,o=novell -p novell -n /media/nss/NSSVOLNAME - 
1 cluster 


8 Migrate the iPrint resource to another OES node in the cluster, then repeat Step 7 until all of the 
OES nodes in the cluster have run the iprint_nss relocate script. 


9 Create the Print Manager and Driver Store on the OES cluster. 


When choosing the target server, use the IP address of the cluster resource. This specifies 
where the driver store and Print Manager database will reside. Begin by using the IP address of 
the new resource. This will need to be changed to a DNS name later by editing the . conf file. 


When you receive a certificate management error, allow the error and proceed. 


While you are creating the Print Manager, the lower dialog box indicates where the Print 
Manager will be located. Specify the IP address of the cluster resource. This changes later to a 
DNS name. 


The iPrint service doesn’t “know” that it's running on a cluster because the script creates a 
symbolic link. If the link exists, you know that the service is clustered. 


10 After you create the Print Manager and Driver Store, modify the /etc/opt/novell/iprint/ 
conf/ipsmd.conf and idsd.conf to have multiple DSServer values. 


For example: 


DSServerl replicaServer 
DSServer2 replicaServer 


DSServer3 replicaServer 
11 Remove the pound sign (#) from the following two lines in the load script: 

exit on error rcnovell-idsd start 

ett ca cares rcenovell-ipsmd start 
12 Offline and online the cluster resource and verify that the Print Manager and Driver Store load. 
13 Create a printer to test that the service is working. 


14 Follow the instructions in “Migrating iPrint to OES 2015 SP1” in the OES 2015 SP1: Migration 
Tool Administration Guide. 


IMPORTANT: When you authenticate to the source and target servers, use the IP address of the 
source Novell Cluster Services iPrint resource (Secondary IP) and the IP address of the target 
Novell Cluster Services iPrint resource (Secondary IP). 


The ipsmd.conf file is located in the /etc/opt/novell/iprint/conf directory 


E.2.7 Transferring AFP in a Cluster 


1 Install AFP on each OES server that will be in the cluster. For details, see the OES 2015 SP1: 
Novell AFP for Linux Administration Guide. 


2 Cluster-enable the AFP service. For details, see “Configuring AFP with Novell Cluster Services 
for an NSS File System” in the OES 2015 SP1: Novell AFP for Linux Administration Guide. 
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E.2.8 Transferring CIFS in a Cluster 


1 Install CIFS on each OES server that will be in the cluster. For details, see the OES 2015 SP1: 
Novell CIFS for Linux Administration Guide. 


2 Cluster-enable the CIFS service. For details, see “Configuring CIFS with Novell Cluster Services 
for an NSS File System” in the OES 2015 SP1: Novell CIFS for Linux Administration Guide. 


E.3 Server Identity Migration 


The following is an example of transferring a NetWare 6.5 SP7 server to an OES server, using the 
Transfer ID option in the OES Migration Tool. 


¢ Section E.3.1, “Preparing and Transferring Your Replica Server,” on page 116 


¢ Section E.3.2, “Post-Migration Steps,” on page 117 


Table E-5 Service Migration Summary 


Pre-Migration (Source Server) Post-Migration (Target Server) 


A NetWare 6.5 SP7 server with the following: An OES server on new hardware with the same 


+ 


+ 


name and eDirectory identity 
eDirectory replicas 


p . : 
NSS volumes for home directories and shared eDirectory replicas 


file systems + NSS volumes for home directories and shared 


An NSS volume for NDPS and iPrint file systems 


DHCP services + An NSS volume for iPrint 


ZENworks for Desktops 7 SP1 IR3a HP3 (or e DMGE Services 


newer update) + ZENworks for Desktops 7 SP1 IR3a HP3 (or 
newer update) 


E.3.1 Preparing and Transferring Your Replica Server 


1 Prepare your servers by following the instructions in “Preparing for Transfer ID” in the OES 2015 
SP1: Migration Tool Administration Guide. 


Make sure you do the following: 


+ 


Install the OES target server in the same context as the NetWare source server, using the 
Novell Pre-Migration Server pattern and the patterns for all services that correspond to the 
services running on the NetWare server. 


This ensures that eDirectory is installed on the target server without a replica and that the 
target server is prepared for all of the services being migrated. 


For instructions, see “Installing OES 2015 SP1 as a New Installation” in the OES 2015 SP1: 
Installation Guide. 


If you are moving data from NSS volumes on the NetWare source server, create 
corresponding NSS volumes on the OES target server. Be sure to use the same names as 
on the source server. 


Do not create any new volumes that will not have data migrated to them until after the 
Identity Transfer migration is completed. 
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¢ Verify that the host name and DNS entries in your local /etc/hosts files and on the DNS 
server are correct. 


+ Apply the latest SLES 11 and OES from the Novell Customer Center to the target server. 
For more information, see “Updating (Patching) an OES 2015 SP1 Server” in the OES 2015 
SP1: Installation Guide. 


+ If the source server is running NetWare 6.5 SP7, install the SMS patch (http:// 
support.novell.com/docs/Readmes/InfoDocument/patchbuilder/readme_5042400.html) first. 
If the source server is running SP8, this is not necessary. 


¢ If you are migrating ZENworks 7 Server Management, delete the Distributor and Subscriber 
objects on the NetWare servers that will be migrated to OES. 


2 Migrate your server by following the instructions in “Using the Migration GUI Tool for Transfer ID” 
in the OES 2015 SP1: Migration Tool Administration Guide. 


Make sure you do the following: 


+ If you are moving data from NSS volumes on the NetWare source server, follow the 
instructions in “Migrating File Systems to OES 2015 SP1” in the OES 2015 SP1: Migration 
Tool Administration Guide. 


¢ If you are migrating Novell ZENworks 7 Desktop Management, migrate the directories 
where you store your MSI, AOT, etc. You do not need to migrate the ZENworks 
program directory itself. 


¢ If you are migrating Novell ZENworks 7 Server Management, migrate the directories 
where you store your user applications, etc. 


+ If you are transferring iPrint, follow the instructions in “Migrating iPrint to OES 2015 SP1” in 
the OES 2015 SP1: Migration Tool Administration Guide. Do not perform the post-migration 
procedures at this point. 


+ If you are transferring DHCP, follow the instructions in “Migrating DHCP to OES 2015 SP1” 
in the OES 2015 SP1: Migration Tool Administration Guide. Do not perform the post- 
migration procedures at this point. 


3 After all the services above have been successfully migrated, click the button to transfer the 
server identity and complete the Transfer ID Wizard. 


E.3.2 Post-Migration Steps 


+ “jPrint” on page 118 
+ “DHCP” on page 118 
+ “ZENworks 7” on page 118 


Examples 117 


iPrint 


1 Complete the remaining iPrint instructions, starting with “Migrating ZENworks iPrint Policies” in 
the OES 2015 SP1: Migration Too! Administration Guide. 


DHCP 


1 Complete the remaining iPrint instructions, starting with “Post-Migration Procedures” in the OES 
2015 SP1: Migration Tool Administration Guide. 


ZENworks 7 


+ “Novell ZENworks 7 Desktop Management” on page 118 
+ “Novell ZENworks 7 Server Management” on page 118 


IMPORTANT: You need the ZENworks for Desktops 7 SP1 IR3a HP4 patch for imaging on 64bit 
Linux. 


Novell ZENworks 7 Desktop Management 


1. Mount the ZENworks 7 Desktop Management Linux CD on the OES server. 
2. Install ZENworks 7 Desktop Management, selecting the features that you will use. 


You can also do the silent install by modifying the silent .properties file and copying it to your 
machine. 


3. Modify each NAL object to reflect the new path to the files on the OES Volume 
4. Modify the Workstation objects so that they have the correct location for the images. 
5. Open the ports in the firewall on the OES server. 


See “Ports used by ZEN” (http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=3880659&sliceld=1&docTypelD=DT_TID_ 
1 _1&dialoglID=22570644&stateld=1%200%2022568512) 


Novell ZENworks 7 Server Management 


1. Install ZENworks 7 Server Management on the OES server 
2. Make sure that the Distributor and Subscriber objects are created. 


IMPORTANT: If you did not delete the objects before the migration (Step 1 on page 116), you 
get an error and they are not created. In this case, all of the paths still point to the NetWare 
volumes and ZENworks 7 Server Management does not function properly. 


3. Resolve the certificates by using ConsoleOne. 


4. Right-click any of the distributions that you created and assign them to the new distributor 
created when you installed ZENworks 7 Server Management on the server. 


5. Access the Distributions that have paths, and modify them with the new paths. 


6. If you were using variables, access the Subscriber and re-create the variables, making sure they 
point to the new location on the OES server. 
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7. Open the ports in the firewall on the OES server. 


See “Ports used by ZEN” (http://www.novell.com/support/php/ 
search.do?cmd=displayKC&docType=kc&externalld=3880659&sliceld=1&docTypelID=DT_TID_ 
1 1&dialogID=22570644&stateld=1%200%2022568512) 
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